PA R K E S | C O N S I D I N E | O L E S E N | B LO U N T

AC C O U N T I N G
INFORMATION
SYSTEMS
FIF T H ED I T I O N
 Accounting
Information Systems
5TH EDITION

Alison Parkes
Brett Considine
Karin Oleson
Yvette Blount
Fifth edition published 2016 by
John Wiley & Sons Australia, Ltd
42 McDougall Street, Milton, Qld, 4064

© John Wiley & Sons, Ltd 2016

Fourth edition published 2012

© Brett Considine, Alison Parkes, Karin Olesen, Yvette Blount, Derek Speer 2012

Third edition published 2010

© Brett Considine, Alison Parkes, Karin Olesen, Derek Speer, Michael Lee 2010

Second edition published 2008

© Brett Considine, Abdul Razeed, Michael Lee, Derek Speer, Philip Collier 2008

First edition published 2005

© Brett Considine, Abdul Razeed, Michael Lee, Philip Collier 2005

Typeset in 10/12 pt Times LT Std

The moral rights of the authors have been asserted.

National Library of Australia

Cataloguing-in-Publication entry

Author: Parkes, Alison, author.

Title: Accounting information systems / Alison Parkes, Brett Considine,
Karin Oleson, Yvette Blount.
Edition: Fifth edition.
ISBN: 9780730325048 (ebook)
Subjects: Accounting — Data processing —Textbooks.
Information storage and retrieval systems — Accounting — Textbooks.
Other Creators/
Contributors: Considine, Brett, author.
Oleson, Karin, author.
Blount, Yvette, author.
Dewey Number: 657.0285

Reproduction and Communication for educational purposes

The Australian Copyright Act 1968 (the Act) allows a maximum of 10% of the pages
of this work or — where this work is divided into chapters — one chapter, whichever
is the greater, to be reproduced and/or communicated by any educational institution
for its educational purposes provided that the educational institution (or the body that
administers it) has given a remuneration notice to Copyright Agency Limited (CAL).

Reproduction and Communication for other purposes

Except as permitted under the Act (for example, a fair dealing for the purposes of study,
research, criticism or review), no part of this book may be reproduced, stored in a retrieval
system, communicated or transmitted in any form or by any means without prior written
permission. All inquiries should be made to the publisher.

The authors and publisher would like to thank the copyright holders, organisations and
individuals for their permission to reproduce copyright material in this book.

Every effort has been made to trace the ownership of copyright material. Information that will
enable the publisher to rectify any error or omission in subsequent editions will be welcome. In
such cases, please contact the Permissions Section of John Wiley & Sons Australia, Ltd.

Cover: © Omelchenko / Shutterstock.com

Typeset in India by Aptara

10 9 8 7 6 5 4 3 2 1
ABOUT THE AUTHORS
Alison Parkes
Associate Professor Alison Parkes is a researcher, educator, consultant and author specialising in
accounting systems. Her professional interests relate to optimising the design of accounting processes
and improving the quality of financial data and decision making. She holds a Bachelor of Commerce
(Accounting), a Masters (Honours) in Business Systems and a PhD in Business Information Systems from
the University of Melbourne. Alison’s practitioner career began in management accounting and progressed
through to managing large-scale financial systems development projects. These years of industry experi-
ence in both accounting and information systems underpin her academic qualifications and are invaluable
in her current role as Director of the MBA program at Taylor’s Business School in Malaysia. Her research
exploring relationships between the behaviour of individuals, the technologies they use and the accounting
tasks they are performing has been published in numerous international conferences and journals.
Brett Considine
Brett Considine’s most recent academic role was as a Lecturer in what is now known as the Department of
Accounting and Corporate Governance at Macquarie University. At Macquarie, he coordinated and taught
units at the undergraduate and postgraduate levels in areas that included introductory financial accounting,
auditing and accounting information systems. He completed a Bachelor of Commerce degree (with
Honours) at Melbourne University in 1999, with a specialisation in Accounting and Accounting Infor-
mation Systems. He has also been a Senior Tutor at the University of Melbourne, teaching in the areas
of accounting information systems and introductory accounting. Brett has also enjoyed an involvement
with a number of the Residential Colleges affiliated with the University of Melbourne, including Trinity,
Ormond, Queen’s, Newman and International House. Additionally, Brett has completed a Graduate
Diploma in Education (Secondary) at Australian Catholic University, has some secondary school teaching
experience and, in a touch of diversity, has experience in the media as a broadcaster.
Karin Olesen
Dr Karin Olesen is a Senior Lecturer in the Graduate School of Management at the University of
Auckland. She holds a Bachelor of Commerce in Accounting and Finance, a Masters with First
Class Honours and a PhD in Information Systems. She has over 25 years’ experience in teaching in
the Accounting and Information Systems and Operations Management Departments across a diverse
range of subjects, including accounting information systems, introductory accounting, advanced finan-
cial reporting, financial modelling, knowledge management systems and digital media production at the
undergraduate and postgraduate levels. The first part of Karin’s career was spent in company and char-
tered accounting as a financial accountant involved in business planning, budgeting, financial reporting,
implementation of accounting systems and taxation preparation for multiple organisations.
Yvette Blount
Dr Yvette Blount is a Senior Lecturer in the Department of Accounting and Corporate Governance at
Macquarie University. She worked in the IT and banking industries for 20 years prior to embarking on
an academic career. Yvette has a Bachelor of Business (MIS), MBA (Professional Accounting) and a
PhD in Information Systems. She has taught accounting information systems and information systems
for management in undergraduate and postgraduate programs at Macquarie University. Her research
interests include the implications of information systems for employee management, technology and
flexible work practices, particularly telework (telecommuting) and the role of technologies in learning
and teaching. This combination of research and industry experience provides a strong basis for teaching
the real-world contexts of information systems. Her research has been published in book chapters and
journals.

ABOUT THE AUTHORS iii

CONTENTS
About the authors iii
Preface xi

PART 1 PART 2

Systems fundamentals 1 Systems characteristics and

considerations 33
CHAPTER 1
CHAPTER 2
Introduction 2
Introduction 3
Business processes 34
1.1 What is an accounting information Introduction 35
system? 4 2.1 Organisational strategy and mission 36
Accounting 4 AIS FOCUS 2.1
1.2 Data and information explained 7 ALDI in the Australian supermarket industry 38
AIS FOCUS 1.1 2.2 Organisational design 39
Loyalty New Zealand — reaping the The functional perspective of the organisation 40
big data rewards 9 2.3 What is a business process? 42
1.3 What is a system? 9 Interlocking activities 42
1.4 Definition and evolution of accounting Across the organisation (the horizontal
information systems 11 perspective) 43
A brief history of accounting information Predetermined goal 43
systems 12 Customer needs 43
1.5 The role of accounting and accounting What is a business process compared with
information 14 a business function? 44
AIS FOCUS 1.2 Business processes within the organisation 45
Using data in the organisation 16 2.4 Why business processes? 45
1.6 Where next? 18 AIS FOCUS 2.2
Part 2: Systems characteristics and Outsourcing business processes for
considerations 18 innovation 47
AIS FOCUS 1.3 End-user perspective 47
Hacktivists ‘Anonymous’ attack Australian 2.5 ERP systems, business processes and
government websites 22 best practice 48
AIS FOCUS 1.4 2.6 Issues in moving to a business process-based
Is your email ready for the summer environment 50
bushfire season? 23 Management change 50
Part 3: Systems in action 25 People change 51
Part 4: Systems issues 27 2.7 Changing business processes 51
Summary 28 Total Quality Management (TQM) 51
Key terms 28 Business process re-engineering (BPR) 52
Discussion questions 29 Technology-driven process improvements 59
Self-test activities 29 AIS FOCUS 2.3
Problems 30 Moraitis lengths ahead 67
Further reading 31
2.8 BPR evaluated 68
Self-test answers 31
Risks and criticisms of BPR 68
Endnotes 32
Acknowledgements 32 2.9 What are Australian organisations doing with
information technology and processes? 69
How are businesses using IT? 69
 Is IT really improving processes? 72 CHAPTER 4
Information as a business 74
Summary 76
Database concepts II 135
Key terms 78 Introduction 136
Discussion questions 78 4.1 Normalisation and database design 137
Self-test activities 79 Database tables and normalisation 139
Problems 79 Definitions 139
Further reading 85 First normal form 140
Self-test answers 85 Second normal form 141
Endnotes 85 Third normal form 144
Acknowledgements 89 Relating the normalised tables — example A 145
Beyond third normal form 146
CHAPTER 3 Further examples of normalisation 146
Relating the normalised tables — examples B
Database concepts I 90 and C 148
Introduction 91 Relating the normalised tables — example D 150
AIS FOCUS 3.1 4.2 Different ways a business works = different
T Construction Industries 92 data structures 153
3.1 The role of databases in decision making and 4.3 Enterprise models 155
reporting systems 92 Developing an enterprise model 155
Design of database models in relational 4.4 The REA Accounting Model 165
databases 93 REA Accounting Model example 168
3.2 Database concepts 94 4.5 Differences between REA and ER
3.3 Data redundancy 98 modelling 170
Modification anomalies 99 4.6 Database implementation 171
Insertion anomalies 99 Client–server systems 171
Deletion anomalies 99 Databases in e-commerce 173
3.4 Database systems and functions 99 Summary 174
Database systems 99 Key terms 175
Advantages of database Discussion questions 175
systems 101 Self-test activities 176
Other database systems 103 Problems 176
3.5 Database modelling, design and Further reading 195
implementation of relational databases 104 Self-test answers 195
Database modelling 105 Endnotes 196
3.6 Database design 109 Acknowledgements 196
Conceptual model entity–relationship
diagram 109 CHAPTER 5

Implementation model 114 Systems development 197

Implementing relationships 114
Introduction 198
AIS FOCUS 3.2 5.1 Business size and complexity 199
Tax Disputes Limited 120
5.2 Systems development life cycle 199
Top-down versus bottom-up
Investigation 201
database design 121
AIS FOCUS 5.1
Summary 122
Supermarkets changing the way you shop 202
Key terms 123
Analysis 207
Discussion questions 124
Self-test activities 127 Design 208
Problems 127 AIS FOCUS 5.2
Further reading 133 Selecting a vendor based on RFPs 213
Self-test answers 134 Implementation 213
Acknowledgements 134 Maintenance and review 217

CONTENTS v
5.3 Alternative systems development Reduced accounting time 251
approaches 218 Recognition by major accounting
Prototyping 219 software vendors 251
Agile/adaptive methods 220 Interchangeable data 252
5.4 Software selection for SMEs 221 Comparisons across companies 252
Pre-developed programs 221 Improved audit quality 252
Types of accounting packages 221 Stakeholder benefits 252
Software as a service 222 6.7 XBRL concepts 253
5.5 Typical problems of systems development 222 XML and XBRL compared to HTML 253
Conflict 222 XBRL specifications 255
Escalation of commitment 222 XBRL taxonomies 256
Project goal issues 223 Instance documents 258
Technical skills 223 Tagging accounts using XBRL 259
Interpersonal skills 223 6.8 Cloud computing 263
5.6 Systems development management tools 224 Cloud Infrastructure as a Service (IaaS) 263
Gantt charts 224 Cloud Platform as a Service (PaaS) 263
CASE 225 Software as a Service (SaaS) 263
Summary 225 6.9 Big data 265
Key terms 226 Other technologies 265
Discussion questions 227 AIS FOCUS 6.1
Self-test activities 228 Phablets for accountants? 266
Problems 229 Summary 267
AIS FOCUS 5.3 Key terms 268
An integrated medical record system 232 Discussion questions 269
Further reading 235 Self-test activities 270
Self-test answers 235 Problems 270
Endnotes 235 Further reading 273
Acknowledgements 237 Self-test answers 273
Endnotes 274
CHAPTER 6 Acknowledgements 274
Technology concepts 238 CHAPTER 7
Introduction 239
6.1 Why an ERP system? 240 Systems mapping and
6.2 Business processes supported by documentation 275
ERP systems 240 Introduction 276
6.3 ERP systems — SAP modules 242 7.1 The purpose of systems documentation 277
Financial accounting (FI) 242 7.2 Role of systems documentation in process
Controlling and profitability analysis (CO) 243 redesign and re-engineering 278
Human resources (HR) 243 7.3 Role of accountant in accurate reporting and
Sales and distribution (SD) 243 preserving corporate memory 278
Materials management (MM) 244 Auditing and systems documentation 279
6.4 XBRL and its role in reporting systems 7.4 The law and systems documentation 280
and decision making 245 7.5 Reading systems documentation 281
6.5 Different ways to apply XBRL tags 247 AIS FOCUS 7.1
XBRL tags in the accounting system 247 The role of software in systems
Tagging accounts after reports have been documentation 282
produced 248 Entities 282
6.6 Benefits of XBRL 249 The narrative 283
Reduced data manipulation 249 Process maps 286
Paperless reporting 251 Data flow diagrams 287
Industry-accepted standards 251 Systems flowcharts 293

vi CONTENTS
7.6 Balancing a data flow diagram 299 Summary 364
7.7 Drawing systems documentation 299 Key terms 365
Analysing the case 301 Discussion questions 366
Preparing a process map 303 Self-test activities 366
Preparing data flow diagrams 307 Problems 367
Further reading 368
7.8 Comparing the different documentation
Self-test answers 368
techniques 317
Endnotes 368
Summary 318
Acknowledgements 372
Key terms 319
Discussion questions 320 CHAPTER 9
Self-test activities 320
Problems 323 Internal controls II 373
Self-test answers 328 Introduction 374
Endnotes 328 9.1 Control activities, business processes and
Acknowledgements 329 accounting 375
9.2 Evaluation of control activities 376
CHAPTER 8
Preventive, detective and corrective controls 377
Internal controls I 330 AIS FOCUS 9.1
Introduction 331 Insider trading: the worst case in
8.1 Evolution of corporate governance 332 Australia? 379
What is corporate governance? 332 Input, processing and output controls 380
Brief history of corporate governance 333 9.3 COSO, COBIT and control activities 380
8.2 Principles of corporate governance in 9.4 Aims of a computerised accounting
Australia 335 information system 382
AIS FOCUS 8.1 Proper authorisation 382
Availability of information to shareholders 336 Proper recording 383
8.3 IT governance 339 Completeness 383
What is IT governance? 339 Timeliness 383
8.4 COBIT framework and principles 340 9.5 General controls 384
Australian IT governance 346 Physical controls 384
AIS FOCUS 8.2 Segregation of duties 385
Governance and accounting failure in Australia 346 User access 385
8.5 Significance of internal control 347 System development procedures 387
What is internal control? 347 User awareness of risks 387
8.6 Components of COSO internal control Data storage procedures 387
framework 349 AIS FOCUS 9.2
Control environment 349 Privilege vulnerabilities 388
Risk assessment 350 Security policies 389
AIS FOCUS 8.3 9.6 Application controls 389
Fuel prices and financials 350 Input controls 389
AIS FOCUS 8.4 AIS FOCUS 9.3
Disaster recovery options 351 Human error: the biggest problem 393
Control activities 353 Processing controls 395
Information and communication 353 Output controls 397
Monitoring 354 AIS FOCUS 9.4
8.7 Identifying and assessing risks 357 Controls in practice 398
Linking risks to financial statement assertions 358 9.7 Disaster recovery plans 399
8.8 Evaluating COSO and COBIT frameworks 361 Temporary sites 399
AIS FOCUS 8.5 Staffing 400
Corporate governance, financial reporting  .  .  .  what Restore business relationships 400
else? 363 9.8 Execution of internal control 400

CONTENTS vii
9.9 Documenting controls 401 Summary 467
Narrative descriptions 401 Key terms 468
Questionnaires and checklists 402 Discussion questions 469
Flowcharts 403 Self-test activities 470
Control matrix 404 Problems 471
Further reading 479
9.10 The limitations of controls 404
Self-test answers 479
Threats to an organisation’s objectives 404
Endnote 479
Threats to internal controls 406
Acknowledgements 480
Summary 407
Key terms 408 CHAPTER 11
Discussion questions 409
Self-test activities 410 Transaction cycle — the
Problems 410
Self-test answers 420
expenditure cycle 481
Endnotes 420 Introduction 482
Acknowledgements 422 11.1 Expenditure cycle overview and
key objectives 483
PART 3 Strategic implications of the expenditure
Systems in action 423 cycle 484
11.2 Technologies underpinning the
CHAPTER 10 expenditure cycle 485
AIS FOCUS 11.1
Transaction cycle — the Getting behind the scenes — managing
revenue cycle 426 your supply chain 486
Introduction 427 11.3 Data and decisions in the expenditure
10.1 Revenue cycle overview and key cycle 486
objectives 427 Data and the expenditure cycle 486
Strategic implications of the revenue cycle 429 Expenditure cycle business decisions 487
AIS FOCUS 10.1 AIS FOCUS 11.2
Simply Energy 430 Accounts payable processing at Telstra 488
10.2 Technologies underpinning the revenue 11.4 Expenditure cycle documentation 488
cycle 430 Expenditure cycle context 489
AIS FOCUS 10.2 Expenditure cycle logical data flows 490
Caffe Primo Chain 431 11.5 Expenditure cycle activities and related risks
10.3 Data and decisions in the revenue cycle 432 and controls 495
Data and the revenue cycle 432 Determine demand for goods — activities,
Revenue cycle business decisions 432 risks and controls 495
10.4 Revenue cycle documentation 433 Order goods — activities, risks and controls 499
Revenue cycle context 433 Receive goods — activities, risks and
Revenue cycle logical data flows 434 controls 505
10.5 Revenue cycle activities and related Pay for goods — activities, risks and controls 512
risks and controls 439 Physical DFD — determine demand for
Process the sales order — activities, risks and goods 520
controls 440 System flowchart — determine demand for
Pick, pack and ship the goods — activities, goods 521
risks and controls 448 11.6 Measuring expenditure cycle
Bill the customer — activities, risks and controls 450 performance 524
Receive and record payment — activities, Summary 524
risks and controls 459 Key terms 526
Physical DFD — process the sales order 463 Discussion questions 527
Systems flowchart — process the sales order 465 Self-test activities 527
10.6 Measuring revenue cycle performance 466 Problems 529

viii CONTENTS
 Further reading 537 Self-test activities 583
Self-test answers 537 Problems 585
Endnote 537 Further reading 593
Acknowledgements 537 Self-test answers 593
Acknowledgements 594
CHAPTER 12
PART 4
Transaction cycle — the general
ledger and financial reporting Systems issues 595
cycle 538 CHAPTER 13
Introduction 539
12.1 General ledger and financial reporting cycle
Auditing and governance
overview and key objectives 539 of accounting information
Strategic implications of the general ledger and systems 596
financial reporting cycle 542
Introduction 597
12.2 Technologies underpinning the general ledger
13.1 Importance of the audit function 598
and financial reporting cycle 542
13.2 Internal auditing 598
AIS FOCUS 12.1
13.3 External auditing 599
Storm clouds ahead: some pros and cons of
data in the cloud 544 13.4 Audit committees 600
12.3 Data and decisions in the general ledger and 13.5 Influences on the auditor 601
financial reporting cycle 545 Benchmarks and best practice 602
Data and the general ledger and financial 13.6 Financial (statutory) audit 602
reporting cycle 545 Requirement for a financial audit 602
AIS FOCUS 12.2 Sarbanes–Oxley Act (SOX)
Online recruiter uses Xero for accounting requirements 603
online 547 13.7 Information systems audit 604
General ledger and financial reporting cycle Overview of the AIS audit 605
business decisions 547 AIS FOCUS 13.1
12.4 General ledger and financial reporting Cloud computing: assessing the risks 606
cycle documentation 549 Audit tools 608
General ledger and financial reporting AIS FOCUS 13.2
cycle context 549 COBIT and IT governance
General ledger and financial reporting cycle case studies 608
logical data flows 554 Planning the audit 613
12.5 General ledger and financial reporting cycle Fieldwork (performing the audit) 617
activities and related risks and controls 556 Analysis 618
Prepare budgets — activities, risks and AIS FOCUS 13.3
controls 556 Protecting customer data 620
Update the general ledger — activities, risks and Completion, review, monitoring and
controls 557 reporting 622
Record general ledger adjustments — activities, Audit of systems under development 623
risks and controls 565 Special purpose audits 623
Produce reports — activities, risks and Summary 624
controls 569 Key terms 624
Physical DFD — prepare budgets 575 Discussion questions 625
Systems flowchart — prepare budgets 576 Self-test activities 626
12.6 Measuring general ledger and financial Problems 627
reporting cycle performance 580 Further reading 630
Summary 580 Self-test answers 631
Key terms 582 Endnotes 631
Discussion questions 582 Acknowledgements 632

CONTENTS ix
 CHAPTER 14 14.4 Cybercrime 649
Malware: viruses, worms, Trojans, bots 650
Ethics and cybercrime 633 Spam 650
Introduction 634 Identity crime 651
14.1 The importance of ethics 634 AIS FOCUS 14.3
Consequentialist theories 635 News of the World 652
Non-consequentialist theories 636 14.5 Fraud, online fraud and scams 652
Importance of ethics in AIS and Sales fraud or e-commerce fraud 654
accounting 637 14.6 Reducing the risk of cybercrime 655
Ethical issues in business 637 14.7 Future trends and issues with
14.2 Ethical decision making 638 new technologies 656
Applying the framework 639 Summary 657
14.3 Ethical issues in accounting information Key terms 658
systems 640 Discussion questions 659
Self-test activities 660
Customer protection and privacy 640
Problems 661
AIS FOCUS 14.1 Further reading 662
Data breaches 641 Self-test answers 663
AIS FOCUS 14.2 Endnotes 663
RFID: Asset tracking capabilities and more 643 Acknowledgements 666

x CONTENTS
PREFACE
The fifth edition of Accounting Information Systems offers a uniquely Australian and New Zealand
perspective of the business processes central to many organisations, and contains additional material
and improved chapter content from the third edition. In order to maximise the benefit of its Australian
and New Zealand context, this text uses, wherever possible, contemporary Australian and New Zealand
examples and issues as a basis for explaining and exploring the many issues associated with accounting
information systems (AIS).

For students
This text offers you an Australian and New Zealand perspective of the AIS discipline. Written by a team
of authors from Australia and New Zealand for a tertiary audience, this text guides you through your
studies in the AIS area. An understanding of accounting information systems is vital for all accounting
areas because throughout your working life you will be using and relying on the technologies and
systems described in this book, and also managing the processes discussed and explored. In recent years,
the need to be abreast of the areas covered in the text has been highlighted by corporate failures and
the financial crisis — each of which saw attention placed on the way organisations operate and the con-
trol structures that they employ. Another area of recent change relates to accounting technologies and
accounting data. In response to recent technological developments, additional materials have been intro-
duced to cover enterprise resource planning (ERP) systems, eXtensible Business Reporting Language
(XBRL), cloud computing, and the ‘big data’ or data analytics phenomenon. This text will help you
successfully complete your studies in the accounting information systems area; you will gain essential
skills and analytical approaches of benefit to you both now and well into the future.

For lecturers
The structure of the text allows teaching in several different ways, depending on the pedagogy of the
instructor and the focus of the course design. The partitioning of the text into four sections provides
flexibility of material delivery that makes sense in most sequence structures. Educationally, the text pro-
vides a range of assessment and learning material and additional end-of-chapter questions and problems.
Each chapter employs a range of small case vignettes to illustrate, using Australian and New Zealand
examples, the main ideas being conveyed in the chapter. Learning objectives relate to the major issues
and themes of the chapter, and are outlined at the commencement of the chapter and then emphasised
in the appropriate spot as each chapter proceeds. The end-of-chapter review materials and problems link
back to the learning objectives. This linkage allows for the setting of targeted questions based on the
emphasis adopted when delivering the material to students. From a student’s perspective, this structure
has definite benefits as well, providing a clear link between the requirements of the question material
and the theoretical concepts discussed throughout the chapter.
Central to the discussion throughout the book is the notion of the business process. As business
processes become increasingly important to the organisation, impacting on organisational design and
operation, the perspective adopted by the text makes it contemporary and relevant. The fifth edition
presents business processes with chapters on the revenue process (chapter 10), expenditure process
(chapter 11) and general ledger and financial reporting (chapter 12). Additional chapters from previous
editions covering the manufacturing process and the human resources management and payroll process
are available through Wiley Custom Select. The scope of these processes offers a complete and com-
prehensive coverage of the typical business processes within the organisation. In addition, the range of
processes included means that the instructor has flexibility in what processes are covered and the extent
of emphasis within the individual AIS course design.

PREFACE xi
 Linked closely to the business process and systems materials is an overview of current technology
trends including XBRL, which introduces a new perspective on financial reporting and accounting infor-
mation systems design. The text also covers the emerging technologies of cloud computing and data
analytics, focusing particularly on how these technologies impact the accounting role. The coverage of
ERP systems has been greatly expanded in this fifth edition.
Overall, much content has been enhanced in the fifth edition, including a new technology concepts
chapter covering ERP, systems applications and products (SAP), cloud computing and big data. Chapters
on internal controls, systems development, and ethics and cybercrime have been extensively revised.
Process maps have been added throughout chapters 10, 11 and 12 to more clearly depict the processes
and create new options for classroom teaching and learning.
Links to the various areas of the typical undergraduate degree are borne out in many topics in the
text — for example, the chapters on systems documentation and systems development. The intent of this
is to reinforce that Accounting Information Systems is not a standalone unit — it has direct relevance to
the various areas of the professional accountant’s roles and responsibilities. This perspective means that
a comprehensive coverage of AIS issues is now offered by the text, as well as greater flexibility in the
selection and sequencing of topics over the course of the semester.
The text offers discussion questions, self-test activities in the form of multiple choice questions, and
problems at the end of each chapter. Much of this material has also been revised and updated for the fifth
edition, including an expanded set of end-of-chapter problems. Many of the AIS Focus vignettes have
been updated.
The authors are grateful for the contributions of colleagues who invested time and effort to prepare the
teaching and learning resources that accompany the text.
Each of the authors would welcome any comments or suggestions about the content of the text and
any suggested changes or improvements for later editions of the text.
Alison Parkes
Brett Considine
Karin Olesen
Yvette Blount
March 2016

xii PREFACE
PART 1
Systems
fundamentals
In part 1 of this text we introduce the fundamental ideas and principles underlying business
information systems. Business information systems are an integral part of any organisation,
providing a means of capturing, organising and sharing data. Accounting information systems are
a specialised form of business information system; they record transactional accounting data,
convert data into information, and provide information to external and internal decision makers.
In this section we also explore these ideas in detail by describing fundamental systems concepts,
explaining the historical development of accounting information systems and discussing a range of
systems-related issues.
Familiarisation with systems fundamentals provides the foundation for subsequent chapters,
which cover the business processes that exist in an organisation, along with the design and
documentation of these systems and processes. Part 1 concludes with an overview and
roadmap of the text and provides brief descriptions of each of the remaining chapters.

1 Introduction 2
CHAPTER 1

Introduction
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

1.1 critically evaluate accounting practices, reflecting on how accounting information systems enrich and
extend the role of the accountant
1.2 compare and contrast data and information
1.3 critique and synthesise system concepts, giving examples
1.4 explain ‘accounting information systems’ and discuss their evolution
1.5 justify and communicate the role of accounting information in supporting decision makers
1.6 understand the environment in which AIS operates and the issues associated with AIS.
Introduction
Welcome to the study of accounting information systems! You are embarking on the study of an area that
will have far-reaching impacts on your professional life. Accounting information systems is a special-
isation offering exciting future-proof career opportunities which greatly increase the value of any busi-
ness degree. Given the pervasive nature of business information systems and technology generally,
accountants are increasingly expected to be able to be competent owners and managers of their special-
ised accounting information systems. Traditional approaches to accounting and audit are becoming less
relevant and effective as the automation of accounting processes and systems becomes widespread. A
related challenge for accountants and auditors is the changing landscape of business data. In addition to
the ability to capture new and potentially valuable streams of data (known as ‘big data’ or data ana-
lytics), the increasing use of online data storage (putting data ‘in the cloud’) poses many challenging
questions about the ownership and management of accounting data. Technology-driven changes have
created an increased demand for accountants who understand the business processes and information
systems in use in organisations.1
Accounting information systems are ubiquitous; you have probably encountered an accounting infor-
mation system in one form or another several times today without even realising it! For example, if you
used public transport, you probably had to validate your ticket before travelling. The act of validating
your ticket creates a transaction, which is captured as a data record in the accounting information system
used by the public transport provider. These millions of individual transactions are summarised and
converted into information which is used to support decision making around issues such as revenue allo-
cation and patronage loads on different routes. If you paid for your ticket electronically, you interacted
with an integrated accounting information system which combined systems from the public transport
provider, their bank and your bank to seamlessly transfer money from your bank account into theirs.

CHAPTER 1 Introduction 3
These simple everyday transactional systems not only directly affect the customer experience, but can
also create a valuable competitive advantage for the systems owner through the unique information they
generate. The value of an accounting information system is directly linked to the quality of information
generated by that system. A well-designed and controlled accounting information system records high-
quality data, provides valuable, insightful information, promotes sound decision making and ensures
ongoing high-level performance for the organisation.
Chapter 1 introduces you to the concept of an accounting information system and discusses some
general principles relevant to the study of accounting information systems, forming a foundation for
subsequent chapters.

1.1 What is an accounting information system?

LEARNING OBJECTIVE 1.1 Critically evaluate accounting practices, reflecting on how accounting
information systems enrich and extend the role of the accountant.
What accounting information systems are has been an ongoing issue for much of the research that has
tried to define the discipline. One of the constant challenges confronting the field of accounting infor-
mation systems is the need to carve out its own area distinct from other disciplines, while being part of
a constantly evolving and changing landscape. This section introduces you to some ideas about what
accounting information systems are, leading to the definition of an accounting information system that is
used throughout the remainder of the text.
We begin our search for the meaning of accounting information systems by going back to first prin-
ciples and looking at the three words individually: ‘accounting’, ‘information’ and ‘system’.

Accounting
As a business student, no doubt you will have some concept of what accounting is and what it involves.
The traditional role of accounting and accountants was to record details of transactions occurring within
an organisation, summarise and adjust that data as necessary, and then to prepare and distribute financial
statements and reports. The traditional accounting cycle typically included the following steps:
1. transaction occurs
2. analyse transaction
3. journalise transaction
4. post journal to ledger
5. prepare trial balance
6. adjust entries
7. adjust trial balance
8. close entries
9. prepare financial statements.
The aim of the accounting cycle was to provide meaningful information for use by decision makers,
both internal and external to the organisation. The accounting process, and the accountants who used that
process, was functionally a data storage and classification system, with transactions tagged and classi-
fied based on the accounts they affected to determine which account to debit and credit when entering a
transaction into the subsidiary and/or general journals. A set or ‘chart’ of accounts was tailored for the
organisation and the total amounts posted to each of these accounts were reported in the form of a ‘trial
balance’ of the general ledger. The modern rules around debits, credits and double-entry accounting
are based on ideas from the Italian mathematician, Luca Pacioli,2 who devised a method of recording
business transactions for the merchants of Venice during the Italian Renaissance. Those early merchants
faced the same issues their modern-day counterparts grapple with. How much have I sold? What is my
profit? To whom do I owe money and when should I pay it?
The primary difference today is that these steps of the cycle are routinely handled by computers rather
than by quill and ink notations made in vellum account books. So the boring and often frustrating task

4 PART 1 Systems fundamentals

of journalising and posting transactions to create financial reports is now performed more efficiently by
accounting information systems. These systems range in scope and complexity from a relatively simple
small business package like Xero or MYOB through to enterprise-wide modular systems such as those
offered by Oracle and SAP. Enterprise systems are typically designated as belonging to one of three tiers
(see figure 1.1). This automation of basic bookkeeping has changed the typical accountant’s role to one
of ensuring data quality, designing and validating usable financial reports, and advising senior corporate
decision makers.

Are all ERP solutions created equal?

There is a multitude of ERP systems available, so how do you decide which one is the right solution? All
ERP solutions are not created equal: one ERP may be too small to meet the needs of your organisation,
while another may be too large. Although other companies in your industry may be choosing to adopt a
particular solution, you need to work out what will work best for your business.
Spending more money up front won’t necessarily give you the best result. Total Cost of Ownership
(TCO) is high for a Tier 1 ERP — both the initial costs and the ongoing maintenance bills will be higher.
Selecting a less expensive Tier 3 ERP might not be the best idea either, as you can end up relying on
other applications to provide missing functionality. Also, you can end up storing crucial data outside the
system and become unable to meet business reporting needs. To help you understand the three ERP
tiers, a summary of each follows.
Tier 1 ERP software solutions
Tier 1 ERP solutions are provided by SAP and Oracle. They are designed for complex global organ-
isations with multiple operating locations and revenues typically in the billions. Tier 1 ERP solutions
contain many complex processes, from providing workflow functionality to supporting multiple users
accessing core functions simultaneously. While these are essential for a global organisation, smaller
companies can be overwhelmed by the overall complexity of these systems. Tier 1 ERP solutions
generally take the longest time to implement, contain a huge array of features and have a high price tag.
Tier 2 ERP software solutions
Tier 2 solutions are less complex and less expensive than Tier 1. Epicor ERP, Infor, Microsoft and Sage,
for example, fall into this group. As mid-sized ERPs suit many businesses, the competition here is fierce.
Both Tier 1 players offer a downsized version of their ERP to meet this market, while many Tier 3 players
are trying to move upmarket for the same reason.
Tier 2 ERP systems fit mid-sized companies with less complex needs than Tier 1 users; however,
the degree of complexity does vary widely. Vertical market players are common in the Tier 2 category,
developing software aimed at a single specialised industry. This helps with achieving fit; however, the
more specialised an ERP system is, the smaller its market will be. This makes Tier 2 vertical market
players more vulnerable to takeover by other players. Horizontal Tier 2 ERP systems providers tend to
be more stable and often offer partnerships with third-party developers to create missing functionalities.
Tier 3 ERP software solutions
At this lowest level, you’ve got Quickbooks, MYOB, Xero and Sage 50, formerly known as Peachtree.
These products generally do not offer the workflows of Tier 1 and Tier 2 solutions, and may not even
qualify as ERP systems. They usually offer only basic accounting functions. Small businesses and busi-
nesses using a business application with poor accounting functionality would benefit from adopting a
Tier 3 solution, as they offer a low TCO and are easy to implement. However, there is some risk that,
as the business expands, it may outgrow this system, but most Tier 3 solutions provide data migration
capabilities for users to upgrade these systems.3

FIGURE 1.1 Three tiers of enterprise systems

Enterprise systems are just one example of how traditional accounting roles have been revolution-
ised and broadened in scope to encompass tasks beyond the traditional accounting functions. Enterprise
systems also emphasise the role that technology has played in changing the perception and functioning
of accounting information systems in the organisation.

CHAPTER 1 Introduction 5
 As computer systems have been developed to perform the recording and classification tasks
associated with business activities, the nature of accounting and the work of the accountant have also
been pushed in a new direction. Increasingly, the role of the accountant is seen to be to add value in
one of two ways: by active ownership and management of the accounting information system, and by
analysing and presenting information to the decision makers in organisations. As an example, look
at the following two quotes from the two major professional accounting bodies in Australia, CPA
Australia (certified practising accountants) and the Institute of Chartered Accountants in Australia
(ICAA).
Under the heading of ‘Why accounting?’, CPA Australia provides the following argument.4

Accounting studies give you the tools to understand how and why key business decisions are made, and
how to have input into those decisions. Having a qualification in accounting will open doors to career
opportunities within: finance and accounting, information technology, marketing, human resource man-
agement, e-commerce, international business, economics, running your own business, management,
strategy and business development.

Similarly, the ICAA defines a chartered accountant (CA) as someone who:5

bring[s] their analytic expertise to fields as diverse as strategic planning, market analysis, compliance,
change management and the use of information technology.

Some of the potential career paths associated with accounting are described in figure 1.2.

The world of professional accounting is bigger than you might think

Accounting positions exist in every part of business and include a wide range of roles, from payroll
officer to CEO or chair of the board. Many CPAs are business leaders. They work in a variety of organ-
isations, including small businesses, large corporations, multi-national investment firms, government
and private practice.
As a CPA, you’ll be equipped with the ability to analyse and interpret financial and non-financial infor-
mation, so you can advise a company on where it stands and where it’s headed. You will be recognised
as a trusted adviser.
Here are a few examples of the positions open to CPAs.

Chief financial officer

Responsible for keeping an organisation financially healthy. This means analysing data, presenting
reports and creating strategies for success. CFOs must also establish the best way to drive a business
to where it needs to go. If you enjoy being in control, this could be the role for you.

Forensic accountant
The detectives of the finance world. They track and analyse data to find missing funds, trace
illegal business activities and identify fraud. It’s a challenging and exciting field that could take you
anywhere.

Counter-terrorism financial investigator

Works with the police on financial matters relating to persons of interest in ongoing investigations.

Environmental accountant
Takes a ‘green’ approach to making money and finds ways to ensure a company is environmentally
responsible and profitable. They enjoy great professional rewards while helping the planet.

International accounting specialist

Part of a network of professionals helping manage cross-border transactions, global trade agreements
and overseas investments. A great career if you like your work fast-paced and ever-changing.

6 PART 1 Systems fundamentals

 Accounting risk analyst
Risk analysts identify any strategic and operational risks. Plus, provide the necessary solutions to help
an organisation cope. You’ll need exceptional analytical skills and the ability to perform under pressure.
Associate at a major accounting firm
All-rounders who manage a range of accounts. Graduates who work for the major accounting firms
are mentored by some of the most experienced accountants in the industry, and look after a variety of
organisations.
Strategic procurement manager
The masterminds behind organisational deals. They perform market research to identify supplier best
practice and capabilities, develop evaluation plans and look after complex contracts. If you have a stra-
tegic mind and the ability to negotiate in tricky situations, this could be the perfect role for you.6

FIGURE 1.2 Careers in accounting

As shown in figure 1.2, the accountant’s role has extended beyond the task of capturing and recording
financial information about an organisation to being someone who provides information and solves prob-
lems for an organisation. The days of the accountant only being the one who maintains the books are
long gone. The career paths mentioned in figure 1.2, however, still rely on a knowledge of accounting.
Accounting is still an important skill to possess — it is just that what is done with those accounting
skills has changed.
Accountants are increasingly exposed to and working with technology and information systems; this
is the major theme of this text. Accountants of the twenty-first century must be comfortable with infor-
mation systems concepts as these systems play an important role in the management and functioning of
the organisation. This shift in definition of accounting and accountants towards a technology- based role
leads to the second component of the subject area: information.

1.2 Data and information explained

LEARNING OBJECTIVE 1.2 Compare and contrast data and information.
The traditional accounting process described in learning objective 1.1 is focused on capturing data about
the organisation’s financial activities. For example, every time a sale is completed, the details of the sale
will be recorded in the sales journal. The details of the sale are the data. Data are the raw facts relating to
or describing a single business transaction or event. For example, the data relating to a sale could include
the sale date, salesperson, customer involved, items purchased, sale price and so on. Every time a sale
occurs, this sales data will be gathered and recorded in the accounting system. The later chapters on data-
base concepts explain the options around data collection and arrangement in databases. The important con-
cept to consider for now is that each organisation chooses which data to collect based on their perceived
reporting needs, so data for a common transaction such as a sale may vary widely between organisations.
This ability to record appropriate data (i.e. only data that is useful to meet user needs) forms an important
part of the quality of the accounting information system. The main details of accounting transactions are
captured in the journals and subsidiary ledgers. Considered individually, these data items are of very little
use to us. For example, consider the data shown in figure 1.3, an extract from a sales journal.
The sales journal in figure 1.3 contains a record of each sale made by the organisation, with each
of these data records consisting of a standardised set of ‘fields’ or types of data related to the business
event of making credit sales to customers. As a basis for decision making, however, this mass of data is
not very useful. To understand why, consider a real-world business that engages in many thousands of
transactions every day. This would mean thousands of individual records being made in the sales journal
in a day. How useful would that be for those who have to make decisions? Probably not very useful at
all. Imagine the task of analysing sales or trying to identify trends in sales and customer sales levels if

CHAPTER 1 Introduction 7
 all you had were the raw data in figure 1.3. It would be very time-consuming, difficult and potentially
inaccurate. So a way is needed to make the data useful.
Data become useful when they are subject to the application of rules or knowledge, which enables
us to convert data into information. Information is a guiding tool for decision making and can prompt
action. The sales data contained in the sales journal in figure 1.3 can be made useful by summarising
them in some meaningful way to support further analysis by decision makers. Examples of this could
include weekly sales summaries, sales by customer reports, profit margins per customer and so on.

Debit Credit
Date Customer Invoice # Accts Rec. COGS GST Payable Sales Inventory

02-6-15 A Bligh 1001 350 180 31.82 318.18 180

04-6-15 A Phillip 1002 121 65 11.00 110.00 65

05-6-15 G Macquarie 1003 143 80 13.00 130.00 80

07-6-15 B Earton 1004 400 200 36.36 363.64 200

08-6-15 B Dulloch 1005 650 400 59.09 590.91 400

09-6-15 S Pine 1006 500 300 45.45 454.55 300

10-6-15 K Riley 1007 423 290 38.45 384.55 290

11-6-15 M Blue 1008 644 500 58.55 585.55 500

12-6-15 D Malchio 1009 1110 670 100.91 1009.09 670

12-6-15 P Star 1010 225 100 20.45 204.55 100

13-6-15 F McGrath 1011   75 39 6.82 68.18 39

14-6-15 B Earton 1012 685 400 62.27 622.73 400

15-6-15 K Riley 1013 590 300 53.64 536.36 300

16-6-15 M Blue 1014 170 80 15.45 154.55 80

17-6-15 M Cook 1015 367 200 33.36 333.64 200

FIGURE 1.3 Example sales journal

To improve usability, the raw data records could also be summarised on the basis of sales by cus-
tomer, sales by geographic region (assuming geographic region data are available), sales by product type
and so on. When this is done, the data become more meaningful and easier to work with. Summarising
the data and turning it into information creates a useful tool to assist decision making. The concept of
data records and their creation and storage is explored in more detail in later chapters examining data-
bases and enterprise information systems.
One key issue with information is the potential to provide too much. This is described as information
overload, which happens when an individual has more information than they need, and as a result
experiences difficulty working through to a decision, which is obviously undesirable. Organisations need
to be conscious of what information they produce (whether reports or some other type of information)
and make sure that it is relevant to the needs of the people who will use it. Commonly in large organ-
isations, people will request reports for a specific problem. Over time, that problem may disappear, yet
the reports are still produced. In many cases, these reports will then just be filed away because ‘that’s
what has always been done’. So resources are wasted in generating the reports and the potential for
information overload and suboptimal decision making is created.

8 PART 1 Systems fundamentals

 As an example of some of the different ways that organisations today are moving beyond conventional
accounting systems for information, read AIS Focus 1.1. This article reports on an initiative by Loyalty
New Zealand to use the large amounts of customer data collected from users of their FlyBuys program
to create new value for customers and retailers. Loyalty New Zealand uses SAS software to profile and
segment customers so as to provide better targeted offers to their customers. This helps not only with
understanding customer purchasing habits, but also provides the ability to customise products for niche
sections of a market and assess purchasing profiles of various consumer types.

AIS FOCUS 1.1

Loyalty New Zealand — reaping the big data rewards

Established in 1996 and based in Wellington and Auckland, Loyalty New Zealand operates a FlyBuys
loyalty program that recognises and rewards customers while also offering over 50 participating busi-
nesses vital information concerning their customers. The vision of Loyalty New Zealand is to create,
maintain and motivate loyal customers for their business partners. With 75 per cent of New Zealand
households being active members of the FlyBuys program, transactional information is systematically
recorded at point-of-sale (POS) terminals when customers use their FlyBuys card. This gives Loyalty
New Zealand access to rapidly growing, vast amounts of customer behaviour data. Loyalty New Zealand
is currently using big data to enhance the benefits and the value customers get by using their cards. Big
data refers to vast amounts of generally unstructured and distributed customer information collected
from various sources such as transactional histories, customer feedback and surveys, social media
applications, mobile device activity and software logs which can be processed by using special appli-
cation software in order to obtain new insight concerning customer behaviour.
Using SAS software, Loyalty New Zealand are enhancing their ability to better understand their cus-
tomers by way of profiling, segmenting and analysing data in order to target customers with meaningful
offers and campaigns that aim at providing the right offer to the right consumer at the right time. With
SAS, Loyalty New Zealand now can develop, scale and launch campaigns within a single day which is
almost 20 times faster than before. Specifically, Loyalty New Zealand now has many new capabilities,
including the ability to carry out highly targeted campaigns, the ability to model behavioural propensity of
consumers and the ability to profile them on the basis of the geographical area of residence and proximity
to business outlets. Customised recommendations can also be provided in real time to customers based
on continuously evolving individual product preferences. For example, recurring patterns of purchases of
baby products could be indicative of a new baby in the family of the cardholder, which can be used as a
basis to offer types of complementary baby products or even information related to relevant promotional
campaigns of businesses that are partners of Loyalty New Zealand in the card­holder’s geographical area
of residence. Recurring patterns of past purchases can also be used as a basis to anticipate the types
of products or services that customers might be likely to purchase into the future. For example, big data
applications can analyse present purchases of toddler products and use findings as a basis to provide
insight into the types of school-aged children’s products that the household is likely to be purchasing in
the near future. Integrating transaction histories from multiple business partners and past customer pref-
erences can also provide insight into what else and from where customers might be likely to purchase
in the future. Taken together, this information can be invaluable to help predict the manner in which cus-
tomers will behave and address it accordingly.7

1.3 What is a system?

LEARNING OBJECTIVE 1.3 Critique and synthesise system concepts, giving examples.
A system is an organised set of principles or procedures created and used to carry out a specific activity.
For the purposes of this text, the systems we discuss rely on the input–processing–output (IPO) model
used in information systems. Information systems receive inputs, process those inputs, and use those
processed inputs to generate outputs.
Inputs are the starting point of a system. The primary inputs for an accounting information system are
the data extracted from each business transaction as it occurs. For example, each time a sales transaction

CHAPTER 1 Introduction 9
occurs, a new sales record is input. Transactions are often recorded initially on source documents that an
organisation generates and receives in its normal business operations. Examples of various source docu-
ments are described in detail in later chapters of this text. These source documents are used to provide
documentary evidence for transactions input into the accounting information system. Transactions can
be input into an accounting system in a number of different ways, including the following.
Most common
•• Manual keying. As the name suggests, manual keying requires a person to enter data into a system via a
keyboard. This could introduce errors in the data if items such as names and amounts were incorrectly
keyed. As any errors are the result of human error, mistakes in the data tend to be random and inconsistent.
•• Scanning through barcode technology. This involves scanning a barcode with a laser device. The
barcode number is then searched for on a database and appropriate details returned to the system.
Examples of this include scanners at a supermarket, where universal product codes are used. As errors
are the result of technology error, mistakes in the data tend to be systematic and consistent.
Less common
•• Scanning through image scanners. Image scanners are a useful input approach where the input is in
the form of a diagram or graphic image. Scanners are used to capture the image, which is then stored
electronically.
•• Magnetic ink character recognition (MICR). This technology is used on bank cheques. A special ink and
character set is used, with computers able to read the ink due to its magnetic properties. MICR offers a
security control for banks and provides a quick method for scanning information into a system.
•• Voice recognition. Using voice recognition technology allows a computer to convert spoken words and
commands into data inputs. Issues with voice recognition technology can include training the system
to recognise words and deal with accents and different voice intonations.
•• Optical mark readers. You have most probably used this technology when completing multiple-choice
exams at university. Data inputs are coded onto a sheet by colouring in the appropriate space, and the
sheet is then fed through a machine that identifies where the dots are and, based on their location,
converts them into data that can be stored electronically. All marks made on the sheet need to be
precise and unambiguous, otherwise high error rates can be experienced.
Processing refers to activities that are performed on the inputs into the system. Again using the sales
system as an example, once sales data are entered into the system, various processing is undertaken,
including checking format and validity, manipulating inputs, and finally storage. Examples of format and
validity checks are discussed in the chapters on the different transaction cycles, as well as the internal
controls chapter, but the basic aim of data processing is ensuring that data are correct and in a valid
format. Manipulations refer to the act of performing calculations and adjusting the data inputs. As an
example, if a sales order is entered and the unit prices and the quantity of units sold are keyed in, the
system can then manipulate these two figures to generate the total price (sales price × units sold). Other
checks and manipulations performed on the data can be hash checks, to ensure that inputs like credit
card numbers and customer numbers are valid. These are discussed in more detail in later chapters.
Outputs refer to what is obtained from a system, or the result of what the system does. In the sales
system, outputs will typically include reports for decision making. Some examples of outputs from the
sales system could be receipts and invoices that are given to customers when a sale is executed, or sales
summary reports used by management to assess performance. When designing a system, it is important
to consider what outputs will eventually be required to ensure sufficient data input to the system to meet
the end-user needs. If, for example, customer details are not gathered when sales data are input into the
sales system, then it will be impossible to generate a sales report that breaks sales down by customer.
Interacting with the inputs, processes and outputs is the control system, which is the set of checks
and balances that ensures that the system is running as expected and that there are no data errors or
exceptional circumstances. For example, if data for a new customer, including a customer number, is
entered into a system, the system could take the customer number data entered and check that it is in
the required format and is a valid number. If the system finds an error in the customer number (e.g. it

10 PART 1 Systems fundamentals

has been entered as alpha-numeric when it should be numeric), then it will alert the data entry person
responsible and prompt them to re-enter the customer number in the correct format. Controls form an
important part of an accounting information system, so several chapters of this text are devoted to the
design and implementation of controls.
One example of a control is booking a flight online through Virgin Australia. If a departure date later
than the return date is entered, the user will get an error message alerting them to the incorrect sequence of
dates (for example, if the departure date was entered as 20 March 2015 and the return date was entered as
4 March 2015, which obviously does not make sense). To help ensure that only accurate and reliable data
enter the system, a control is put in place which advises the user that this sequence of dates is not accept-
able. The transaction will not be recorded until the date sequence has been input correctly. The design
and implementation of controls is usually the responsibility of a specialised system or risk accountant, or
a management accountant. Enforcing compliance with controls is a general management responsibility.
Checking compliance with controls is the responsibility of external and internal auditors. As many controls
are visible to customers and employees, it is important to ensure that controls are easy to use and unlikely
to offend or annoy. In 2015, a major Australian telecommunications provider issued a public apology after
an error message stated that the title of ‘Dr’ did not match the gender of the name (‘Rachel Cook’).
Any system needs to have a defined task or domain to which it is applied — one system cannot do
everything. This is the idea of system scope: the domain that a system addresses. Systems also operate
within a particular external environment, or context, which will affect the operation of the system. As
an example, an accounting system within an organisation has the scope of preparing the financial reports
that the organisation provides to its shareholders and other dependent users of the financial information.
The financial reporting system operates within the environment of the relevant accounting rules, regu-
lations, generally accepted accounting principles (GAAP) and standards that govern accounting prac-
tice. These rules and regulations are established externally through bodies such as the federal and state
governments and the Australian Accounting Standards Board (AASB), yet they have a definite impact on
the way that the accounting system is designed and operates within an organisation.
The idea of a system is an important one for the remainder of this text. Throughout the text, a range
of different systems and processes that operate throughout organisations will be examined. As you will
see, each of these systems can be broken down and analysed in terms of their inputs, processes and
outputs. The systems analysed include the revenue, expenditure and general ledger systems. These three
systems form the financial spine of most organisations and an understanding of the inputs, processes
and outputs within them is essential knowledge for an accountant. They are also examples of a generic
transaction processing system (TPS), which are systems designed to capture and record recurrent events
that occur in a business’s operations. They can be customised to different types of transactions, including
a purchasing TPS to handle purchases, a human resources TPS to handle payroll and associated human
resources transactions, a sales TPS to handle sales activities and so on.

1.4 Definition and evolution of accounting

information systems
LEARNING OBJECTIVE 1.4 Explain ‘accounting information systems’ and discuss their evolution.
From the above discussion, an accounting information system can be defined as deploying a tech-
nology solution to capture, verify, store, sort and report financial data relating to an organisation’s
activities. This encompasses the definitions of accounting, information and systems as discussed above.
Bear in mind that the definition of an accounting information system includes technology that currently
would mean computer technology. However, as was discussed in the introduction to systems, a system
does not have to be computerised. An accounting information system could operate manually; however,
the reality for organisations today is that most accounting systems are computerised, so this text assumes
some degree of computerisation exists in all accounting information systems.

CHAPTER 1 Introduction 11
A brief history of accounting information systems
Perspectives on accounting information systems, as well as their role within the organisation, have
changed over the years. It is fairly uncontroversial to say that nowadays ‘the joint deployment of tra­
ditional accounting processes and computer and telecommunications technology for financial and man-
agerial accounting purposes’8 is common. While accounting as a bookkeeping function can be performed
manually, most organisations have computerised their accounting process to some extent, ranging from
a stand-alone PC with a package such as MYOB running on it to the large organisation that implements
an ERP system throughout the organisation to manage all business processes. This section presents an
historical perspective on the development of the accounting information systems function, drawing on
Kee (1993) and Badua & Watkins (2011).9
Record keeping and systems have always been present in organisations. From the clay tablets used by
the Sumerians to the paper ledger books described by Pacioli long before the introduction of computers
and today’s computerised records, history is riddled with record keeping relating to commerce. (If you
are interested in a discussion on ancient history and the evidence of recording systems, The Accounting
Historians Journal is a useful reference.) The essential functions of any accounting system have always
been the collection, organisation, storage, retrieval and processing of details pertaining to economic
activity.
Pacioli’s development of the double-entry accounting system was the first real step towards a classifi-
cation scheme and framework for converting data about economic events into useful information about
business performance. Before the emergence of double-entry accounting techniques, record keeping was
based mainly around recording economic activity — that is, gathering data. These data were seldom
summarised or converted into information.
The first double-entry accounting systems were operated manually, which created a great potential for
errors and inaccuracies during the capturing, transcription and classification of data, as well as during
the reporting of information. In the late 1800s, firms began to create less labour-intensive devices for
operating their accounting information systems, including adding machines and cash registers. These
developments allowed for data to be more efficiently captured and provided for the use of batch totals
within the organisation. This emergence of batch totals is significant in terms of the controls that operate
in the organisation today, evidenced in later chapters on internal controls.
Punch cards were later developed as a means of data entry and storage, and IBM emerged in the
marketplace with several developments in machines that were able to verify, sort and total data, hand­
ling debits and credits. Punch cards introduced flexibility into a firm’s accounting information system,
because the individual cards could be sorted and processed in a variety of ways to attain different
results — for example, sales by product, region and so on — that the traditional sales journal struggled
with. Emerging in the accounting information system from these innovations was the ability to apply
different perspectives to data to convert them into information.
This historical perspective is much more than just a fascinating narrative. What it represents is the
development of the accounting information system. Up until the development of machines, the system
operated manually and those who performed the accounting process knew the system and its techni-
calities — for example, the role of journals, ledgers, chart of accounts and so on. This changed with the
introduction of technology into the accounting information system. Suddenly it required two domains of
experience: a technical aspect to run the machines and an accounting aspect to do the accounting for the
organisation. This is the early origin of the accounting and information system subgroups. Data manage-
ment and technical requirements were the domain of what may now be called the information systems
group, while the rules of accounting were the domain of the accounting group. Within an organisation,
the relative balance between these two groups has changed over time, as reflected in figure 1.4.
Until the 1970s, information systems were seen as a support tool for the accounting function: the tech-
nology was provided to enable accounting to be done better. Information systems were almost a subset
of the accounting function, acting in support of the accounting requirements.

12 PART 1 Systems fundamentals

 As technology continued to develop, including management information systems, database tech-
nology and electronic data processing technologies, and with the emergence of the microcomputer,
organisations began to see that the technology of the computer could be applied beyond the domain
of the accounting function. The effect of this realisation was that the information systems function
began to develop an identity of its own, becoming more distinct from the accounting function, which
had previously subsumed it. This is shown in figure 1.4 by the two intersecting circles. Accounting
was still an important function, but information systems had grown in prominence. Information
systems were still used in accounting, as represented by the intersection of the circles, labelled ‘AIS’
in the figure.

1970s

Accounting

Information
systems

Accounting

Information
AIS systems

Information
systems

Accounting

Now

FIGURE 1.4 Accounting and information systems — a changing relationship

Source: Sutton & Arnold 2002.10

As these new techniques emerged, the accounting function’s reliance on the information systems
function increased. As Kee observes, ‘The cumulative effect of computer technology has been further
absorption of much of accounting’s traditional data management function by EDP [electronic data pro-
cessing] professionals. Thus, accounting has become increasing[ly] separate from the technology and
data used to implement its function.’11

CHAPTER 1 Introduction 13
 The reliance on the information services function has extended beyond just the accounting function,
with multipurpose applications and technologies and other developments emerging. Examples include
ideas such as cloud-based data storage, linked databases and the integration of organisations through
online technologies.
Such developments mean that information systems technologies are being incorporated into other
functional areas of the organisation apart from accounting. From the organisation’s perspective, this
increases the role of information systems within the organisation and makes the other functional areas
dependent on the information systems function. It also means that more information flows occur than
previously and these might involve external parties.12 The advent of the internet and e-commerce has
profoundly and irrevocably changed the way organisations and their suppliers and customers interact,
create and share accounting data.
The traditional function of accounting as a provider of financial reports is also being affected by
technology. As questions are raised about the timeliness of annual reports and their usefulness to
decision making by shareholders and other like parties, there is increased discussion about the pros-
pect of real-time reporting of financial information.13 Again, this places the accounting function in a
position where it depends on the communication and storage technologies of the information systems
division. This final shift of power from accounting is represented in the bottom part of figure 1.4,
with the accounting function a subset or part of the information systems function. The role of the
accountant now necessarily includes understanding and managing the accounting information systems
on which they rely.
Thus what can be seen is a gradual change in the relationship between accounting, information
systems and the rest of the organisation. This has developed from the days before computer technology
where record keeping was the primary focus, to the emergence of double-entry recording, which enabled
classification of data to generate accounting information, to the stage where computer technology now
pervades the whole organisation and accounting is just one of the functions that depend on the technol-
ogies of information systems.

1.5 The role of accounting and accounting

information
LEARNING OBJECTIVE 1.5 Justify and communicate the role of accounting information in supporting
decision makers.
Accounting information is central to many activities within and beyond an organisation. As is evident
from the definition and discussion of accounting in the earlier part of this chapter, accounting’s role is
to gather data about a business’s activities, provide a means for the data’s storage and processing, and
then convert those data into useful information. The information that can be generated by an accounting
information system is diverse. No doubt you are familiar with the typical accounting statements that are
produced by the accounting process, including the income statement (or statement of comprehensive
income), the statement of financial position (or balance sheet) and the statement of cash flows. These
reports represent information generated by the accounting system to support decision making by external
and internal decision makers. This financial information is used by providers of economic resources in
making decisions about whether to invest in a company, as well as for evaluating company performance
at the end of the financial year. Financial reports are also scrutinised by regulatory bodies such as the
Australian Securities and Investments Commission (ASIC) and the Australian Tax Office (ATO) for
compliance with relevant corporate legislation.
The statements of accounting concepts issued by the Australian Accounting Research Foundation pro-
vide particular guidance on the role accounting information plays in everyday society. Some of the
purposes of accounting information mentioned in the Statement of Accounting Concepts 2: Objective
of General Purpose Financial Reporting14 are assessing whether a business is operating profitably and

14 PART 1 Systems fundamentals

making sufficient cash flows, assessing the ability of a supplier to continue operating into the future
and provide goods or services, and generally assessing whether the business is achieving its aims and
objectives.
However, the traditional financial statements are by no means the only source of information avail-
able through the accounting information system. The general purpose financial statements are used by
shareholders and potential shareholders, creditors and debtors alike, to assess the above dimensions.
Accounting information is also of great value to decision makers within an organisation. Within an
organisation, employees have access to the data that are stored and can query and manipulate them in
various ways to answer questions that may arise in the day-to-day running of the organisation. It is not
practical for employees to rely solely on the general purpose financial statements, since they are pro-
duced once a year (twice in some instances) and very quickly lose their time relevance. In addition, to
preserve valuable corporate intelligence, reports designed for external use tend to contain highly sum-
marised data, whereas internal reports are generally much more detailed.
What sort of decisions requiring accounting information need to be made within a firm? Consider the
following hypothetical examples.
1. A customer wants to make a purchase on their store credit card.
2. The business needs to decide how much inventory to order for the coming month.
3. The organisation needs to assess the potential for bad debts at the end of the financial year.
4. Managers need to evaluate the performance of the factory staff and how well resources have been
used in production.
How can accounting information be used in each of these scenarios? How can accounting information
other than that contained in the traditional financial statements be used?
1. A customer wants to make a purchase on their store credit card. In this situation, accounting infor-
mation can be used as a tool for deciding whether to approve the credit sale. The store may check
the customer’s credit history, including any past defaults on payment, to determine their credit-
worthiness. Additionally, the account balance already owed by this customer may be compared to
the customer’s individual credit limit, to assess whether there is sufficient space on the customer’s
account for the transaction to proceed. In this example can be seen the use of accounting infor-
mation as a part of the authorisation process: if the customer’s credit history is satisfactory, then
the credit sale will be authorised to proceed. Many organisations have developed computerised
processes for credit rating and approvals which draw upon the accounting data gathered by the
accounting information system and use pre-defined algorithms to automate the credit approval
decision.
2. The business needs to decide how much inventory to order for the coming month. When
deciding how much to purchase from suppliers, an organisation needs to have an estimate for
its expected sales in the coming month, because it does not want to purchase too much or too
little stock. Estimates of sales and demand for the product can be gained in a variety of ways,
one of which is to forecast based on past sales figures and trends. In addition to predicted sales
data, the organisation needs to know how much stock they currently have on hand, how much
stock has been ordered but not yet received, and how much stock has been sold to customers
but not yet delivered. Underlying this seemingly simple decision are many different items of the
accounting data. In this example, accounting information is being used as a planning tool within
the organisation.
3. The organisation needs to assess potential bad debts at the end of the financial year. When companies
prepare their financial statements at the end of the financial year, they are required to assess the value
of their accounts receivable account, to establish whether it represents a true and fair value. This task
is performed to avoid any potential misstatement and overvaluation of the assets in their statement of
financial position. If they suspect that not all the accounts receivable will actually be received from
customers, then they estimate the amount that will not be collected and place it in a provision for bad
and doubtful debts. How do they estimate the value of this provision? There are several techniques

CHAPTER 1 Introduction 15
 available, including an ageing analysis of accounts receivable and a percentage of credit sales tech-
nique. Both of these techniques rely on accounting data: the ageing analysis uses accounting data
on amounts owed to the organisation classified by the age of the debt to produce information about
the age breakdowns of accounts receivable. Past sales, ageing information and bad debts information
stored in the accounting information system can also be used to estimate probabilities of a debt in
an age group going bad. Thus the accounting data and information used to generate such estimates
are essential parts of the organisation’s decision making and reporting. The information used in this
example is not restricted to financial statement information — information about the age of accounts
receivable and the probability of debtor default is not generally made public. However, it would
usually be available to those within the organisation, through the accounting information system, for
decision-making purposes such as valuing bad debts.
4. Managers need to evaluate the performance of the factory staff and how well resources have been
used in production. Organisational performance depends on many factors and can be assessed in
many different ways. One area that a manufacturing organisation will be concerned about is how
well its production process is converting raw materials into finished goods for resale to customers.
Accounting information plays a role in evaluating this aspect of business performance, with budgets
and variance reports key assessment tools. At the commencement of the accounting period, organ-
isations will have a budget for manufacturing levels, which will forecast materials usage based on
expected production levels. At the end of the period, management will rescale the budget, based on
actual levels of production, and compare this rescaled budget to actual costs and material usage. Any
significant differences between actual and budgeted outcome will be followed up and investigated by
management. This is an example of accounting information being used as a control tool within the
organisation.
AIS Focus 1.2 discusses how the current trend of production and retention of ‘big data’ has generated
a need for tools capable of analysing and presenting complex data in a form useful to decision makers,
focusing on data visualisation. The earlier example of FlyBuys and their use of data (AIS Focus 1.1) is
another example of the application of data within the organisation to assist in improving business perfor-
mance and solving business problems.

AIS FOCUS 1.2

Using data in the organisation

Enterprise software: The big trends and why they matter
Big data is one of the many buzzwords to have swarmed the tech world in recent memory, but those
on the front lines say the concept is far from fledgling. The idea of collecting data to gain insights spans
industries and has been happening in various — sometimes primitive — ways for several decades.
However, it’s only in the last few years that the concept proved its staying power, with advancements
in technology making it possible to produce unfathomable amounts of data about how people behave.
Two years ago it was estimated the world economy produced 2.5 exabytes of data per day, and
research firm IDC forecasts that we will generate 40 zettabytes of data by 2020. That surfeit of data
unlocked a trove of potential for the entities standing to benefit from it — including government bodies,
education systems, hospitals and retailers — as well as for enterprise business intelligence providers
ready to pounce on the prospect of boosting their product portfolios.
Big data: an old story
Through the implementation of enterprise applications, old-guard vendors such as IBM, Oracle and SAP
have long been capturing enterprise data, and in recent years have joined the race to make that data
fit for insightful analysis. ‘Big data has been around a long time,’ said Byron Banks, VP of big data for
SAP. ‘Now with social media, the Internet of Things, sensor data, mobile devices — new big data has
transformed the business.’

16 PART 1 Systems fundamentals

 As traditional enterprise data took its modern shape, vendors started using BI tools like in-memory
computing, batch-based architectures and the integration of products like Hadoop. In addition to tra-
ditional enterprise data, companies are accruing unstructured information from places far beyond the
confines of corporate walls, creating a stream of complexities for app vendors trying to keep their seats
on the big data bandwagon.
Banks described how SAP has taken its HANA platform and extended it so it can talk to Hadoop,
and how the company changed its business intelligence portal by adding Lumira so end users can see
the data in a visual pattern. ‘At SAP we are evolving our landscape, since we don’t think it’s a rip-and-
replace strategy,’ Banks said. ‘All of the systems that have been built over the years are being improved
upon rather than totally taken away. The whole idea is to extend existing apps into the big data realm
rather than throw away apps that have been built up for 20 years.’

Legacy vendors versus agile upstarts

Still, some skeptics question legacy vendors and their ability to offer big data solutions without simply
rebranding or pursuing acquisitions, as companies are incrementally partnering more with third-party
providers. ‘A lot of the legacy companies are buying into big data,’ said David Steinberg, CEO of Zeta
Interactive. ‘Oracle with Responsys, Salesforce.com with ExactTarget, IBM with Silverpop — a lot of
these guys are buying assets that are very focused on big data specifically, which is smart because they
can triple them quickly by rolling them into their customer base.’
Naysayers also accuse legacy vendors of having a price-fuelled identity crisis when faced with inno-
vative competitors driving down market costs. Companies like Splunk and Cloudera can appear far
more agile than their legacy predecessors by offering products at a cheaper rate than traditional enter-
prise applications.
As for SAP, Banks recognised the challenges of the acquisition approach to big data, but said
it’s the forward-thinking vendors who can keep up with change that will end up faring the best.
‘Big data is a useful technology, just like relational databases were useful technology, and there are
going to be more that we can’t predict,’ Banks said. ‘There will be new providers coming all the time
and we will work with them. There’s probably some guy or gal out there right now who [is] going
to invent something tremendous, and we will adopt that too if and when it makes sense for our
business.’
For the sake of SAP and other vendors’ profit margins, adapting to new technologies will be requi-
site if they intend to maintain and secure customers. Big data technology moves at a frenetic pace,
but companies using it aren’t concerned with how long something takes to get to market — they
want the best product, and fast. ‘Customers expect big data, it’s assumed in today’s world when
you are working with an enterprise,’ noted Zeta Interactive’s Steinberg. ‘Companies on the customer
side are not talking to vendors that can’t bring them better data and better analytics than what they
were doing before.’
It’s that mainstreaming of big data that’s sure to cull the pool of vendors down to those who manage
to execute it best.15

A related issue for an organisation is being clear on how the data that are being gathered and
stored relate to the business processes within it. This broader issue of data management is a
very real problem for organisations, with one of the major problems being that organisations are
simply unaware of what data are being gathered. This makes the role of understanding what data
are being gathered critical, because if it is not known what is being gathered, then how can it poss­
ibly be used? One approach that is an important early step for an organisation is data classification,
which is ‘a fundamental process that drives value throughout an organisation by enabling the align-
ment of information to best address business needs’.16 Data classification involves understanding
the organisation, its processes and the data necessary to support those processes. This helps ensure
that the right data can be converted into useful information for those who need it, thus helping the
organisation realise the full value potential of the data it is gathering. The later chapters on data-
base concepts will help you understand how to design and manage the databases that contain your
financial data.

CHAPTER 1 Introduction 17
1.6 Where next?
LEARNING OBJECTIVE 1.6 Understand the environment in which AIS operates and the issues
associated with AIS.
The chapters of this text are conceptually grouped into four sections. Their relationship is
illustrated in figure 1.5. Part 1 introduces you to the role of accounting information systems, providing
the background for the environment in which the AIS operates. In part 2 we explore the characteristics
and operational issues associated with systems within the organisation. This discussion starts with an
overview of what a business process is, and then considers the underlying technologies in chapters
exploring databases, systems development and technology concepts. Part 2 also covers how business
processes are documented, issues in capturing data within a business process, and controls that can be
used to monitor data quality and process operations. With this conceptual background in hand, we then
progress to part 3 where we examine three specific accounting processes or transaction cycles. These are
the revenue, expenditure, and general ledger and financial reporting transaction cycles. Each of these is
described in a way that highlights the major design issues and control considerations, in order to crys-
tallise the application of the concepts discussed in part 2 and to highlight the importance of business
process operation to the success of the organisation. In part 4 we consider some of the overarching issues
relating to the operation and design of systems and processes, including auditing of systems and ethical
issues related to systems. As a result, the issues and concepts discussed in this section can be seen as the
macro issues confronting systems within the organisation. A brief explanation of the content and type
of issues addressed in each of the chapters in parts 2, 3 and 4 is outlined below, setting the scene for the
remainder of the text.

Part 2: Systems characteristics and considerations

In part 2 we look at some of the issues to consider when designing the operation of systems within
the organisation, including the way systems are implemented to fit within the structure of the organ-
isation and its business processes, and how data is gathered, stored and managed within the processes
and systems, the systems are documented, and the control structures put in place to facilitate the smooth
running of systems. These topics are addressed in chapters 2 through to 9, and briefly introduced below.

Chapter 2: Business processes

Business processes are a key part of how an organisation attains its objectives. They represent the
series of activities that, when combined, deliver something of value to the customer, whether internal
or external. The discussion commences with a look at the broader issues of organisational mission and
strategy. These involve the organisation setting its broad objectives and thinking about how such objec-
tives will be achieved. The attainment of objectives requires a set of activities to be put in place and this
is where business processes are important. Business processes represent the engine room of the organ-
isation — the means by which the goals of the organisation are translated into specific activities that
need to be carried out to achieve its goals. This makes business processes increasingly relevant to organ-
isations as the push for value-added organisational design gains prominence. Therefore, organisations
have started to ask how they can redesign their business processes to maximise the contribution they
make to the organisation. Design of a repetitive process such as a sales process which could be instan-
tiated thousands or even millions of time determines not only the efficiency and effectiveness of that
business transaction but also the standard of customer service and the eventual financial performance
of the company. The business process focus has led to the adoption of organisational change techniques
such as continuous improvement and business process redesign. Consideration of how organisations use
information technology within their business processes is also covered in this chapter, highlighting how
technology must be congruent with the organisation’s mission, strategy and business process design to
add value to the organisation.

18 PART 1 Systems fundamentals

 Part 1
Systems
fundamentals

Part 2
Systems
characteristics
and
considerations

Part 3
Systems in
action

Part 4
Systems
issues

FIGURE 1.5 Structure of topics in the text

Chapters 3 and 4: Database concepts

Recall from earlier in this chapter that data represent the raw facts about an event or activity. There are several
options the organisation can pursue when making decisions about the storage of data, with different database
design alternatives providing an example of this choice. In chapter 3 you will be introduced to the process
that an organisation will follow in determining what data to store and the structures to put in place for man-
aging such storage. The key issue in making these determinations is the accuracy, reliability and timeliness
of the data. You will note that these themes recur in much of the discussion in the remainder of the text. One
of the commonly employed approaches is the relational database approach, which looks for relationships
between different pieces of data as a means of logically connecting them. You will see that the relational
approach offers several advantages for organisations in managing and using the tremendous amounts of
data that move through an organisation. In the past, many organisations have found themselves in a position
where data was duplicated across the organisation (i.e. the same data was stored in numerous locations). We
will see a link between the material discussed in chapter 2, where the evolution of the business process is dis-
cussed, and the emergence of the relational database as an organisation-wide tool, potentially leading to ERP
systems, which are discussed later in the text.

CHAPTER 1 Introduction 19
 Any database, however, is more than just computer software. Rather, a database represents the
culmination of people, procedures, hardware, software and data. These elements combine to assist the
organisation in managing its data resources. A key aspect of the operation of a database system is the
associated documentation that captures the underlying design and structure of the database. To support
this function, we are introduced to the entity-relationship diagram technique as a way of showing the
logical design of the database from a top-down perspective. This is a technique that is used to show the
relationships between different pieces of data — a key to the relational database model.
In chapter 4, the database design concepts are taken a step further as we look at normalisation and the
process of arriving at appropriate data models for a database within an organisation. Normalisation is
an important process in database design, since it works to minimise potential anomalies that can emerge
in a data management system. Normalisation ensures all the lower level operational aspects are also
included, as normalisation starts with the tables, forms and data of the organisation. Once both the top-
down entity-relationship diagram technique and the bottom-up normalisation process are applied, they
are reconciled to ensure that an organisation-wide database model, or enterprise model, is created that
includes the upper level view as well as the operational data.
Chapter 5: Systems development
As an owner of an accounting information system, accountants inevitably will be involved with projects that
seek to upgrade or replace the system. Issues that emerge as part of this undertaking include questions about
how the organisation can manage change within its business process. The reality is that the environment
and the needs of the organisation will change over time, necessitating systems development. Regardless of
whether you intend to work strictly in the accounting domain or extend beyond accounting, as a working
professional you will encounter some form of systems development project. Whether your role is providing
input into the design of a new accounting system, or managing the implementation of a system, systems
development will affect the way you carry out your day-to-day roles and responsibilities. Systems develop-
ment will be a part of your professional accounting career. The systems development chapter introduces you
to some techniques and methodologies that show how an accounting information system, indeed systems in
general, are developed and managed within an organisation. The systems development area is unique in that
it often requires the organisation to broach both technical (i.e. hardware, programming) and non-technical
issues (professional requirements, user thoughts, impact on people, strategy). This has the potential to make
systems development an area where a knowledgeable accountant can make a valuable contribution to their
organisation.
As an example of this integrated approach to systems development, refer to figure 1.6, which describes
how an equipment hire firm used a customer-focused agile development method to design and implement
their online B2B hire portal. This approach involved investing time in understanding customer needs and
expectations via prototyping before creating the final product.

Coates Hire has 125+ years’ experience in providing excellent customer service. When customers started
asking for better ways to do business, the Coates IT team swung into action, creating a multidevice B2B
web portal in partnership with Oakton technology consultants.
The first stage of the project built understanding of customers and their needs. Then a technology solution
was identified that would add value for Coates and their customers. The choice of an agile development
method was essential to the successful rapid development of their online equipment management tool —
MyCoatesHire. This seemingly simple web portal required integration with Coates’ existing ERP and CRM
systems to create a seamless experience for customers. Microsoft Dynamics and Microsoft SharePoint were
used to integrate existing data relating to customers, finance, equipment information and service history.
According to Matt Freedman, Oakton’s director of digital and information, the 12-month project involved a
user-centric design approach. This was carried out in multiple stages including a six-week design phase and
a period for initial research and workshops, followed by nine lots of three-week Scrum sprints. ‘It was really
a multi-stage approach where you’re constantly focusing on the customer and then go through iterations,
continually testing them, so at the end of the day you actually give the customer what they want.’

20 PART 1 Systems fundamentals

 Oakton also helped Coates develop a digital strategy approach to show how customer needs change over
the customer life cycle. Typical customer interactions were mapped out using observation, interview and work-
shop techniques. The pain points identified were given extra attention as these held the key to improving the
customer experience. A series of interactive prototypes were built and tested to make sure that the eventual
solution met customer needs while remaining technically feasible. The prototype team spent many hours
working with customers and internal stakeholders as the prototype progressed through multiple iterations.
The new portal, MyCoatesHire, was implemented in under 12 months and offers better control of
costs, along with improved safety and reliability of equipment for Coates Hire and its customers.17

FIGURE 1.6 Integrated web portal MyCoatesHire built using agile approach

Systems development is inherently linked to the concepts covered in parts 2 and 3 of the text. In car-
rying out systems development, many of the issues raised in earlier chapters (e.g. business process design,
systems documentation, data requirements, enterprise information systems and internal controls) will need
to be considered. Systems development is an organisation-wide task involving people from a cross-section of
the business. Systems design will also impact on the operation of traditional business processes, potentially
changing the types of activities performed and the means by which these activities are executed. The practical
reality for any business process is that it will undergo change as new technologies emerge or the competi-
tive environment evolves. The interaction between technologies and processes and the need for them to fit
together means that difficult decisions often need to be made as to whether to modify technology or a busi-
ness process. Assisting with, or leading, these changes to systems and processes is much better facilitated and
managed by an accountant who has knowledge of systems development techniques.
Chapter 6: Technology concepts
Chapter 6 explores how the nature of accounting is changing due to changes in business computing tech-
nology and the widespread adoption of these technologies. The chapter has four parts; in the first part enterprise
resource planning systems (ERP systems) are outlined and an ERP system’s (SAP — Systems Applications
and Products in Data Processing) major modules are described and illustrated. The second part of the chapter
covers the technology XBRL, which is a standard for the electronic communication of business and financial
data. Adoption of XBRL is improving business reporting globally, and it is set to become the standard for busi-
ness reporting. The third section explains how cloud-based computing uses remote computing facilities to pro-
vide business software, hardware and infrastructure that is accessed over the Internet. Lastly the chapter looks
at the phenomenon of big data, exploring how such data can be collected, stored and analysed.
Chapter 7: System mapping and documentation
The role of systems documentation is crucial for an organisation, serving a purpose in systems develop-
ment and systems review, and in recording a process’s operation for new staff and external auditors. Sys-
tems documentation also serves as an important corporate memory device for the organisation, recording
how business processes are designed, the data that moves through the processes and the activities that
occur within the processes. The ability to accurately document a system is an important skill for both
accountants and auditors, as it vastly improves the ability to understand and analyse the information
system. Many differing techniques are available to document a business process, including process maps,
data flow diagrams and systems flowcharts. In this chapter we introduce these common documentation
techniques and show how to read and prepare such documentation. This knowledge is extremely useful
for accounting graduates, as accounting firms value employees who can offer an information systems
perspective in conjunction with traditional accounting skills.

Chapters 8 and 9: Internal controls

Having gained a familiarity with the concept of business processes, technology concepts and systems
documentation, the issue we are confronted with in this chapter is that of achieving control over the
use of the system. Essentially, even with the best designed processes and systems in place, structures,

CHAPTER 1 Introduction 21
policies and procedures need to be designed and implemented to manage risks that have the potential to
interfere with an organisation achieving its goals. The organisational response to risks commences with
a sound policy of corporate governance and extends to the management and use of technology and the
implementation of procedures at the operational level of the organisation to mitigate risk exposure.
Internal controls are instigated across the organisation to manage financial risk exposure (e.g. the
possibility that financial reports could be materially misstated as a result of an error or irregularity such
as a transaction being entered incorrectly or classified incorrectly), as well as exposure that does not
necessarily have a direct consequence for the financial statements (e.g. being subject to specific legis-
lative requirements relating to pollution discharge or noise levels). Recent threats against organisations’
information technology resources have also meant that appropriate controls to protect access to tech-
nology resources need to be given serious consideration. Businesses of all sizes need to be aware of the
multiple risks that confront their resources, including their information-based resources.
The attack by hacktivists of Australian government websites described in AIS Focus 1.3 reinforces the
necessity for strict internal controls.

AIS FOCUS 1.3

Hacktivists ‘Anonymous’ attack Australian government websites

Anonymous is a loosely associated international group of hackers and activists that is well known
for a number of widely publicised hacks and distributed denial-of-service (DDoS) attacks perpetrated
on government, religious and corporate websites. The Anonymous group has become increasingly
renowned for these acts of collaborative, international hacktivism.
Hacktivism is a combination of political activism and computer hacking. Like normal activism except
that it takes place online rather than in a physical sit-in, a DDoS attack is usually executed against the
targeted website. Instead of using graffiti, hacktivists have defaced websites. Generally, Anonymous
uses individual or group computer hacking skills, the internet and technology to try to effect social
change, protest or spread a message of awareness or ideas relating to a particular cause. It communi-
cates its activities more broadly using social media tools like Twitter.
In August 2012, two Twitter accounts claiming to represent the Anonymous group had been boasting
that it would attack both the Australian Secret Intelligence Organisation (ASIO) and Australian Signals
Directorate (ASD) websites. Then Anonymous Australia announced via Twitter that Operation Australia
hackers were busy attacking the ASD and ASIO spy agency’s government website which had been
down or loading slowly for some time. ASIO later described this as their website suffering some tech-
nical issues and that the disruptions did not represent a risk to ASIO’s business.
This attack was only part of a number of DDoS attacks and website defacement campaigns levelled
against 10 Australian government agencies. Furthermore, Anonymous activists had also taken customer
records and data belonging to business telco AAPT and posted the information on a public website.
This action was undertaken to highlight the concerns regarding the then Federal Government’s draft
internet surveillance and security legislative proposal to force Australian telco companies to store and
retain every Australian’s web history data for two years. This exemplifies a hacktivism protest action.
However, after some high-profile arrests, hacker groups similar to Anonymous are changing the way
they operate. For instance, on 5 November 2012 hackers under the name of Anonymous wanting to
highlight Guy Fawkes Day undertook a hacking operation to deface a number of Australian websites,
including the Fremantle Arts Centre, the Clinical Practice Guidelines Portal for medical professionals and
the Quality of Life disability support network. Previously, hackers claiming to be aligned to Anonymous
had only undertaken their acts of hacktivism based on the values of social justice and freedom of infor-
mation. However, public recriminations and loss of support for the cause can be swift once hackers
begin attacking art, medical and disability websites.
Once public sympathy is lost, like any activism or protest it loses impetus and tends to be consigned to
just another event in history. Yet the potential remains for hacktivism to continue when passionate causes
arise in terms of social justice, freedom of information, awareness or communicating a message or alter-
native point of view. However, rather than using the largely illegal actions of hacking websites, stealing, or
damaging or publishing sensitive data, activists are now turning to social media as a responsible means of
communication and as a legitimate avenue for garnering support and spreading their message.18

22 PART 1 Systems fundamentals

 Internal controls are an important part of any system, representing a way of providing a degree of
assurance that the organisation and its systems are running normally, and of preventing, detecting and
correcting anomalous and undesirable occurrences, such as fraud, theft and errors in data. They also
encompass methods that the organisation may employ to help guarantee its ability to operate in the event
of natural disasters and other catastrophic disruptions. The area of disaster recovery is one that is often
ignored by businesses since the perceived threat of a disaster is remote at best. This issue is discussed in
AIS Focus 1.4.

AIS FOCUS 1.4

Is your email ready for the summer bushfire season?

You may not think fires, floods, or tropical cyclones have anything to do with your workplace email —
until one goes through your (or your service provider’s) datacentre, that is. As the summer approaches,
Aussie IT managers could find their holidays rudely interrupted if they don’t have a robust disaster
recovery plan in place, particularly for critical employee platforms like email. According to Gartner,
depending on your industry, network downtime can typically cost around $5600 per minute or more
than $300  000 per hour, on average. If you’re an IT manager hoping to have a 100 per cent uptime break
this summer, you need to treat email like the critical system it is, and avoid making these six mistakes
that could jeopardise business continuity — and your job.
1. Not testing your continuity solution. You’ve devised and implemented what you believe to be a solid
continuity solution, but you’ve not given it a production test. Instead, you cross your fingers and
hope when (and if) the time comes, the solution works as planned. There are two major problems
with not testing your plan from the start. First, things get dusty over time. It’s possible the technology
no longer works, or worse, maybe it was not properly configured in the first place. Plus, you might
not be regularly backing up critical systems.
  Without testing the solution, you’ll learn the hard way that data is not being entirely backed up
when you perform the restore. Second, when it comes to planning, you need a clear chain of com-
mand, should disaster strike. If your network goes down, you need to know who to call, immedi-
ately. Performing testing once simply is not enough. You need to test your solution once a year, at a
minimum. Depending on the tolerance of your business, you’ll likely have to test more frequently, like
quarterly or even monthly.
2. Forgetting to test fail back. Testing the failover capabilities of your continuity solution is only half the
job. Are you prepared for downtime that could last hours, days or even weeks? The ability to go from
the primary datacentre to the secondary one — then reverting back — is critical. This needs to be
tested. You need to know that data can be restored into normal systems after downtime.
3. Assuming you can easily engage the continuity solution. It’s common to plan for ‘normal’ disasters
like power outages and hardware failure. But in the event of something more severe, like a bushfire or
flood, you need to know how difficult it is to trigger a failover. Also, you need to know where you need
to be. For example, can you trigger the failover from your office or datacentre? It’s critical to know
where the necessary tools are located and how long it’ll take you or your team to locate them. Phys-
ical access is critical. Distribute tools to multiple datacentres, as well as your local environment.
4. Excluding policy enforcement. When an outage occurs, you must still account for regulatory and
policy-based requirements that impact email communications. This includes archiving, continuity
and security policies. Otherwise, you risk non-compliance.
5. Trusting agreed RTP and RPO. In reality, you’ve got to balance risk and budget. When an outage
happens, will the email downtime agreed upon by the business really stick? In other words, will the
CEO really be able to tolerate no access to email for two hours? And will it be acceptable for cus-
tomers to be out of touch with you for one day? The cost associated with RTO and RPO could cause
a gap in data restore. If you budget for a two-day email restore, be prepared that during an outage,
this realistically means two days without email for the entire organisation. As part of your testing
methodology, you may discover that you need more or less time to back up and restore data — par-
ticularly in holiday season when personnel resources and support staff may be scarce. It’s possible
that, as a result, you may need to implement more resilient technology — like moving from risky tape
backup to more scalable and accessible cloud storage.

(continued)

CHAPTER 1 Introduction 23
 AIS FOCUS 1.4 (continued)

6. Neglecting to include cloud services. Even when you implement cloud technologies to deliver key services,
such as email, you still have the responsibility of planning for disruptions. Your cloud vendor will include dis-
aster recovery planning on their end to provide reliable services, but mishaps — and disasters — still happen.
Mitigate this risk by stacking multi-vendor solutions wherever possible to ensure redundancy, especially for
services like high availability gateways in front of cloud-based email services, or cloud backups of key data.
With the proper testing and upfront business continuity preparation, you can significantly reduce — or
even prevent — email downtime, data leakage and financial loss after disaster strikes.19

As shown in figure 1.7, by the end of part 2 of the text, the linkages between process and technology con-
cepts begin to emerge. In pursuing its strategy, an organisation designs its business processes in a particular
way. As part of designing business processes, there is a need to consider what data will be generated and
required. This creates a two-way interaction between business process design and database design shown
as link 1. Business processes and database design, in turn, both impact the development of the system, as
shown in links 2 and 3. Once design is complete, the database and system will be implemented using appro-
priate technologies to support system use. Database choices and systems development are directly affected
by available technology options, as shown in links 4 and 5. The organisation requires a record of the busi-
ness process, including the activities that occur, the people involved, and the data and paperwork that move
through the process. This leads to the preparation of the systems documentation, as shown in link 6. Organ-
isations will typically consider process design (link 7), the technology used in the organisation (link 8) and
the systems documentation (link 9) when considering how best to identify and control for the risks of their
information system. In turn, the internal control choices made will impact the activities and people involved
in executing the business processes, so link 8 has been drawn as a two-way interaction.

Chapter 2 Chapters 3 and 4

1
Business processes Database concepts

4
2 3

Chapter 5 Chapter 6
5
Systems development Technology concepts

Chapter 7
8 Systems mapping and 9
documentation

Chapters 8 and 9
Internal controls

FIGURE 1.7 Linkages between part 2 concepts

24 PART 1 Systems fundamentals

Part 3: Systems in action
In this section of the text you will examine the application of the concepts introduced in part 2 to
some specific examples of business processes that operate within a wide range of businesses. These
examples of transaction cycles that occur within a business are central to the business being able
to attain its objectives. Each cycle operates through a series of activities aimed at achieving a par-
ticular goal or solving a particular problem within the organisation. Each chapter describes the gen-
eric business process and systems documentation in detail, along with a discussion of relevant risks
and controls.

Chapter 10: Revenue cycle

The revenue cycle is central to an organisation’s ability to generate cash. It covers selling goods to cus-
tomers and turning these sales into cash receipts as soon as possible. Typical activities that form a part
of the revenue cycle include receiving customer orders, checking a customer’s credit history, approving
a sale, packing and shipping the goods for delivery to the customer, sending an invoice to the customer
and receiving the cash from the customer. From an organisation’s cash management perspective, the
time it takes to convert sales into cash will ideally be shorter than the time it takes to pay accounts pay-
able. If this is not the case, then the business can run in to cash flow problems. Therefore, the efficient
operation of the revenue cycle is important to a business’s liquidity.

Chapter 11: Expenditure cycle

The expenditure cycle is an example of a business process. It is centred on the organisation’s
purchasing activities, and aims to acquire goods from suppliers to meet customer demand. It will
also handle the payment for those purchases as and when they are due. As for the revenue cycle,
the functioning of the expenditure cycle is important for an organisation, and its operation is closely
linked to a business’s liquidity. Typical activities in the latter part of the expenditure cycle include
receiving invoices from suppliers, confirming that goods have been received in a suitable condition,
preparing a cheque requisition, authorising the cheque, sending the cheque, updating the organ­
isation’s records with the details of the payment, and ensuring relevant details are recorded in the
general ledger.

Chapter 12: General ledger and financial reporting cycle

The general ledger and financial reporting cycle is, in effect, the culmination of other cycles
within the organisation, and covers maintenance of the organisation’s accounting records. This
cycle receives a great deal of data from the revenue and expenditure cycles, which is used to pre-
pare and update journals and ledger accounts. Periodically, this cycle will prepare end-of-period
adjusting entries and close the temporary accounts to profit and loss. Trial balances will also be pre-
pared, with a set of financial statements to provide to shareholders being the main output from this
process. Budgeting and forecasting activities can also be aided by the general ledger and financial
reporting cycle.
In summary, part 3 looks at how the concepts from part 2 are applied to the typical business pro-
cesses in an organisation. As you progress through chapters 10, 11 and 12, you will notice some linkages
between the processes, which reinforce the concept that data needs to be shared across the organisation
and between the various business processes. To illustrate this, figure 1.8 gives examples of the inter-
relationships between a range of business processes together with an explanation of the flow of infor-
mation and data between the various processes.

CHAPTER 1 Introduction 25
 Production
HR and payroll process
process 3

Revenue Expenditure
process 1 process
Chapter 10 Chapter 11
7

6
8 5

General ledger
and financial
reporting process
Chapter 12

FIGURE 1.8 Linkages between business processes

Flow Explanation
1 The sales department will send data about sales forecasts or order levels to the expenditure process
so that appropriate levels of goods can be ordered to meet customer demand. The expenditure
process in turn will advise sales when goods are available to be sent to the customer.
2 The revenue process will forward data to the HR process so sales staff can be paid (e.g. based on
hours worked or commissions based on sales levels). Details about staff sales levels may also be
used for performance review purposes.
3 The revenue process will communicate with the production process in the case of a manufacturing
organisation, with sales forecasts determining planned production levels and raw material acquisition.
Similarly, manufacturing will inform sales staff about finished goods or goods approaching completion.
4 Manufacturing will communicate with the expenditure process to request the necessary raw materials
and resources required for production. Expenditure will advise manufacturing when materials will be
available so manufacturing can accurately schedule their future production.
5 The expenditure cycle will communicate with the general ledger and financial reporting cycle so
that details about expenditure are appropriately included in the accounting records. This will include
updating ledger accounts and including the data in the financial statements.
6 HR will communicate with the general ledger and financial reporting process so that details about
payroll-related items, including leave and other entitlements claimed by employees, are incorporated
into the accounts. Provisions for annual leave, long service leave, income tax payable and sick leave
will then be updated. The details will also impact on the profit and loss through line items such as
salaries expenses and annual leave expenses.

26 PART 1 Systems fundamentals

 Flow Explanation

7 Production will communicate with the general ledger and financial reporting process to update the
ledger accounts with the details of goods produced or in the process of being produced. This will
impact on statement of financial position accounts such as finished goods, work in process and raw
materials. Profit and loss will also be affected by the allocation of direct costs used in manufacturing
and the overhead costs accumulated as goods move through the production process.

8 Sales will communicate with the general ledger and financial reporting process so that details about
sales and revenue-related activities can be appropriately included in the accounting records; for
example, revenue in the income statement, the balance of accounts receivable on the statement of
financial position and the cash receipts from customers on the statement of cash flows.

Part 4: Systems issues

The issues considered in the final part are the macro type issues that apply across the organisation and
its collection of business processes, specifically ethics and auditing. In this final section, with the knowl-
edge that you will have acquired about systems concepts and process examples, you will be able to take a
step back and place the operation of the processes in the broader context of the organisation. In addition,
issues of how the technology is used and the risk of inappropriate use of technology emerge, raising eth-
ical considerations in the operation of the various processes. The role of monitoring process operation
also becomes important, with internal audit filling this capacity.

Chapter 13: Auditing and governance of accounting information systems

The requirement for companies to undergo financial statement audits has been longstanding. In recent times,
as organisations have become increasingly computerised, the approach used by auditors for financial state-
ment audits has been modified to take into account the increased reliance on computerised information
systems in capturing financial data and using this data to prepare financial statements. The new emphasis
includes increased attention to how computerised systems are designed, implemented, operated and con-
trolled within the day-to-day operations of the organisations. There are many factors that will impact on the
way an auditor goes about the audit of an information system, with these including legislative requirements
(e.g. the impact of the Sarbanes–Oxley Act in the United States), professional requirements, prescriptions
of the various auditing standards and the unique characteristics of the individual client. In chapter 13 we
consider these aspects in more detail and examine the responsibilities of the audit function in relation to
accounting information systems, as well as the stages involved in performing an AIS audit.
Chapter 13 is strongly linked to the concepts discussed in chapter 2 on business processes and chap-
ters 8 and 9 on internal controls. That is, much of the focus, for both internal and external auditors, is
about assessing the risks within a business process and evaluating the extent to which internal controls
have been put in place and how well these controls operate.

Chapter 14: Ethics and cybercrime

Ethics is concerned with how we act and how we make decisions. In recent years, the corporate world
has been plagued by cases where employees and management have made unethical decisions, with the
consequences, in many cases, being extreme. These have highlighted how actions have consequences
and that there is a real need to consider implications of corporate behaviour. For the accountant, ethics
is an important part of everyday professional life. The professional bodies have ethical standards that
members must follow, and engagement with clients needs to be carried out in an ethical manner. This
extends to the accounting information system, and the need to be aware of the potential for fraudulent
and unethical behaviour that could be perpetrated. The ethics chapter introduces you to the background
of some of the ethical theories that are available for working through ethical dilemmas and then demon-
strates their applicability to the accounting profession by describing some of the ethical issues associ-
ated with the accounting information system. It also provides you with some background and statistics

CHAPTER 1 Introduction 27
relating to the Australian and New Zealand business environment and the incidence of fraud, computer
crime and technology usage in organisations and provides an overview of the problem of fraud and other
types of crime that could impact on the organisation.

SUMMARY
1.1 Critically evaluate accounting practices, reflecting on how accounting information
systems enrich and extend the role of the accountant.
The traditional role of accounting and accountants was recording the details of an organisation’s trans-
actions. The accounting process, and the accountants who were part of that process, acted as a data
classification and storage system. Transactions were classified based on the accounts they affected,
these accounts were detailed in the general journal and then the amounts were posted to the respective
accounts that appeared in the general ledger. Journalising and posting transactions, as well as preparing
trial balances and financial statements, is now performed in a highly efficient manner by computerised
information systems. Increasingly, the role of the accountant is to add value by providing and inter-
preting information for the organisation. The role of the accountant has changed from a recorder of data
to a user of information and owner of the accounting information system.
1.2 Compare and contrast data and information.
Data are raw facts relating to or describing an event. Information is the product of applying rules to data
to make them meaningful. Information is summarised and classified data used by decision makers. This
task of converting data to information is part of the role of a system.
1.3 Critique and synthesise system concepts, giving examples.
A system takes inputs captured through various means, processes these inputs and generates useful out-
puts for decision makers and users of information.
1.4 Explain ‘accounting information systems’ and discuss their evolution.
Accounting information systems involved information processing long before the dawn of computer tech-
nology. However, with the advent of computers came the decline in the power of accounting divisions in
organisations. Once having a powerful influence over an organisation since it captured, recorded and stored
data, as well as produced information from that data, accounting has seen its position eroded by the birth
of what is now referred to as information systems. With the emergence of information systems came new
storage technologies over which accountants did not have control, so the two functions were forced to work
together. As technology continued to develop, accounting became increasingly dependent on information
systems to the point where it is now viewed as a subset of business information systems.
1.5 Justify and communicate the role of accounting information in supporting decision makers.
Accounting information is central to many different activities inside and outside an organisation. The
information that can be generated by an accounting information system is diverse and informs the
decisions of internal and external stakeholders. Data such as sales, purchases and cash flows are used in
summarised form by external decision makers and in detailed form by internal decision makers.
1.6 Understand the environment in which AIS operates and the issues associated with AIS.
The chapters of this text are conceptually grouped into four parts. Part 1 introduces you to the role of
AIS and the background in which AIS operates. Part 2 explores the characteristics and operation issues
associated with AIS. Part 3 examines three specific accounting processes or transaction cycles and part 4
considers issues relating to the operation and design of systems and processes.

KEY TERMS
Accounting information system The application of technology to the capturing, verifying, storing,
sorting and reporting of data relating to an organisation’s activities.

28 PART 1 Systems fundamentals

Controls The set of checks and balances that ensures the system is running as expected and that there
are no data errors or exceptional circumstances.
Data Raw facts relating to or describing a single business transaction or event.
External environment The factors or pressures outside a system that influence its design and operation.
Information overload The situation where an individual has more information than is needed or is
able to be processed in a meaningful way when working through to a decision.
Inputs Data and other resources that are the starting point for a system.
Outputs What is obtained from a system, or the result of what the system does.
Processing Activities that are performed on the inputs into the system.
System An organised set of principles or procedures created and used to carry out a specific activity.
System scope The domain or problem that a system addresses.

DISCUSSION QUESTIONS
1.1 Describe some inputs, processes and outputs of an accounting information system.(LO1, LO2, LO3)
1.2 What is the difference between data and information? (LO2)
1.3 What is information overload? Why might it happen? What are its consequences?(LO2)
1.4 Briefly summarise the changing relationship between accounting and information systems.(LO4)
1.5 Compare the role of the accountant today to their role before the introduction of computer
technology. How have the responsibilities and duties changed over time?(LO4)
1.6 What are some of the uses of accounting information? Provide five examples of how
accounting information may be used and who it would be used by.(LO5)

SELF-TEST ACTIVITIES
1.1 Information is: (LO2)
(a) a summarised version of data about an organisation’s activities.
(b) prepared through the application of processing rules and procedures.
(c) meant to be useful for those who receive it.
(d) all of the above.
1.2 A system: (LO3)
(a) is the combination of inputs, processes, outputs and controls.
(b) is only influenced by internal factors.
(c) addresses a specific process.
(d) can be used to carry out any activity.
1.3 Data is: (LO2)
(a) useful for decision making.
(b) best captured using technology.
(c) best used by an organisation when linked to the processes that generate or require them.
(d) managed by data-mining technology.
1.4 An example of an external factor affecting an expenditure system is: (LO3)
(a) how many suppliers the organisation uses.
(b) the government’s requirement to record and pay Goods and Services Tax (GST) for some
purchases.
(c) a request by an employee for a new report to be added to the system.
(d) a line employee requesting information about the current year’s expenditure.
1.5 MICR technology offers benefits to organisations that: (LO5)
(a) want to ensure no fraudulent transactions occur.
(b) need security in data processing.

CHAPTER 1 Introduction 29
 (c) make lots of payments by cheque.
(d) are looking for an efficient means of processing data.
1.6 Which are correct? An accounting information system must (i) capture inputs, (ii) process data,
(iii) prepare report outputs, (iv) be computerised, (v) store data, (vi) verify data inputs are correct. (LO4)
(a) i, ii, iii, iv
(b) ii, iii, iv, v
(c) i, ii, ii, iv, v, vi
(d) i, ii, v, vi
1.7 Which of the following could be examples of controls in an airline’s online reservation system?
(i) A message asking for confirmation of chosen flight dates, (ii) a link to a web page of an
affiliated car rental company, (iii) a page seeking confirmation of payment details, (iv) a message
informing the buyer that no flights are available at the chosen time, (v) a pop-up screen which
appears once the transaction is completed, containing the buyer’s updated frequent flyer points
balance. (LO5)
(a) i, ii, iii, iv (c) i, ii, iii, v
(b) ii, iii, iv, v (d) i, iii, iv, v
1.8 The accounting function: (LO1)
(a) has never changed.
(b) has typically become more involved with information systems.
(c) has become less dependent on data storage and processing technologies, thus decreasing its
reliance on information systems.
(d) is typically no longer present within the organisation.

PROBLEMS
1.1 Consider the following data input techniques: manual keying via a keyboard, and barcode
scanning. Describe the characteristics of the data errors you would expect to find in data captured
using each of these methods. (LO2, L05)
1.2 You are responsible for advising a grocery retailer on appropriate data capture techniques for
its sales system. The grocery retailer makes approximately 1000 sales per day per store, and
has 20 stores. Considering the errors you anticipated occurring in problem 1.1, choose the most
appropriate input technique and advise management on its strengths and weaknesses and why it is
the best option for the organisation. Would you give the same advice to a grocery retailer with a
single store making 20 sales per day? If not, then why not? (LO1, L02, L05)
1.3 The chapter discussed the idea of a system and its components. Construct a table listing
some of the likely inputs, processing, and outputs for each of the following accounting
information systems: (LO3, L04)
(a) a university enrolment system
(b) an online sales system for a small manufacturer
(c) an airline ticketing system
(d) a large retail store sales system.
1.4 Describe some of the external influences that would likely affect the accounting information
systems listed in question 1.3. To what extent do you think these influences would dictate the
design of an accounting system? (LO4)
1.5 Based on the information contained in this chapter, along with your prior knowledge of
accounting, critically assess the following statement: ‘Accounting is an information system’. (LO3, L04)
1.6 Conduct a web search of the big accounting firms and identify some of the skills they are typically
looking for in graduates. Do they seem to be emphasising accounting skills or information skills,
or both? Why do you think this is so? (LO1)

30 PART 1 Systems fundamentals

1.7 A computer science student says to you, ‘Studying accounting information systems is no use
unless you are a programmer who understands how to build that system’. How would you
respond to such a statement? Do you think the computer science student is correct? Why? (LO1, L04)
1.8 Read AIS Focus 1.1 ‘Loyalty New Zealand — reaping the big data rewards’,
and answer the following: (L02, L03)
(a) Why would grocery retailers share their customer data with Loyalty NZ? What are the main
corporate risks around such data sharing?
(b) What are some of the issues you could foresee around the ownership of customer data in
these sorts of projects?
(c) What would be some of the expected benefits of this project?
(d) How do you think the categorisation project would be viewed by consumers? Would your
answer be different if you were a parent who started receiving offers relating to the next life
cycle stage of your family?
1.9 Given the data in figure 1.3, use an excel spreadsheet or similar to prepare an example
of a report that could be generated using this data. Who would typically use your
report, and why would this information be useful to them? (L02, L05)
1.10 Read figure 1.6 ‘Integrated web portal MyCoatesHire built using agile approach’,
and answer the following: (L04, L05)
(a) What created the need for this online system?
(b) What are some of the people-based issues that may be confronted in making the switch from
face-to-face to online sales?
(c) What are some of the technology-based issues that could be confronted in making the switch
from face-to-face to online sales?
(d) Why do you think Coates prototyped this system before finalising the design?
(e) What has Coates done (or what could it do) to encourage acceptance of the new system?
1.11 Read AIS Focus 1.3 ‘Hacktivists “Anonymous” attack Australian government websites’
and answer the following: (L01, L05)
(a) What do you think of ASIO’s public response to this attack? How would you respond if you
were the CIO?
(b) What are the potential benefits of hacktivism? Do you think this sort of activity can achieve
these benefits?
(c) How would these acts of hacktivism impact the users and owners of the websites involved?
1.12 Read AIS Focus 1.4 ‘Is your email ready for the summer bushfire season?’ and answer the
following: (L01, L02)
(a) Identify the main difference between email and other types of corporate data.
(b) Do you think it likely that email messages are accounting data? How about emailed file
attachments — could they be accounting data?
(c) How many of the six issues listed in the article would apply to all business information
systems? Who do you think should be responsible for addressing these issues — the CIO, the
CFO or someone else?

FURTHER READING
Baltzan, P, Lynch, K & Blakey, P 2012, Business driven information systems, McGraw Hill, North
Ryde, NSW.
Galliers, RD & Leidner, DE (eds) 2009, Strategic information management: challenges and strategies
in managing information systems, 4th edn, Routledge, New York.
Robey, D 2014, ‘Change management’, in Wiley encyclopedia of management, http://onlinelibrary.wiley
.com/doi/10.1002/9781118785317.weom070004/abstract.

CHAPTER 1 Introduction 31
SELF-TEST ANSWERS
1.1 d, 1.2 a, 1.3 c, 1.4 b, 1.5 c, 1.6 c, 1.7 d, 1.8 b

ENDNOTES
1. Sutton, SG 2000, ‘The changing face of accounting in an information technology dominated world’, International Journal of
Accounting Information Systems, vol. 1, no. 1, pp. 1–8; Jeppesen, KK 1998, ‘Reinventing auditing, redefining consulting and
independence’, The European Accounting Review, vol. 7, no. 3, pp. 517–39; Elliot, RK 1994, ‘Confronting the future: choices
for the attest function’, Accounting Horizons, vol. 8, no. 3, pp. 106–24.
2. Pacioli, L 1494, Summa de Arithmetica geometria proportioni et proportionalita, Paganino de Paganini, Venice.
3. Compudata 2013, ‘The difference between ERP Tier 1, ERP Tier 2, and ERP Tier 3’, 8 March, www.compudata.com/
difference-between-erp-tier-1-erp-tier-2-erp-tier-3/.
4. CPA Australia 2009, ‘Why accounting?’, www.cpacareers.com.au.
5. The Institute of Chartered Accountants in Australia 2009, ‘About chartered accountants?’, www.charteredaccountants.com.au.
6. CPA Australia 2009, ‘Where will I end up?’, www.cpaaustralia.com.au/become-a-cpa/what-could-you-do-as-a-cpa.
7. www.loyalty.co.nz/aboutus; V Morder 2013, ‘Insight on Loyalty’s approach to big data’, www.sas.com/offices/asiapacific/sp/
usergroups/sunz/Vince_Morder.pdf; www.sas.com/success/loyaltynz.html; www.loyalty.co.nz/whatwedo/loyaltyprogrammes;
B Bennett 2013, ‘Big data big rewards’, New Zealand Management, vol. 60, no. 3, pp. 28–36; K Jackson 2013, ‘Big data key
for small business’, www.stuff.co.nz/business/small-business/8987045/Big-data-key-for-small-business; D Paredes 2013, ‘Big
data demystified’, www.cio.co.nz/article/439724/big_data_demystified; www.sas.com/success/loyaltynz.html.
8. Badua, FA & Watkins, AL 2011, ‘Too young to have a history? Using data analysis techniques to reveal trends and shifts in
the brief history of accounting information systems’, The Accounting Historians Journal, pp. 75–103.
9. Kee, R 1993, Data processing technology and accounting: a historical perspective, The Accounting Historians Journal, pp. 187–216.
10. Sutton, S & Arnold, V 2002, ‘Foundations and frameworks for AIS research’, in V Arnold & S Sutton (eds), Researching
accounting as an information systems discipline, American Accounting Association, Florida, USA, p. 5.
11. Kee, p. 187.
12. Elliot 1994.
13. Elliot 1994.
14. Australian Accounting Research Foundation 2004, ‘Statement of accounting concepts 2: objective of general purpose financial
reporting’, in J Knapp & S Kemp, Accounting handbook 2003, vol. 1, Prentice Hall, Sydney.
15. Gagliordi, N 2014, ‘The impact of big data on enterprise apps’, ZDNet, 1 May, www.zdnet.com/article/
the-impact-of-big-data-on-enterprise-apps/.
16. Heers, M 2004, ‘Data classification can make or break your business’, ZDNet Australia, www.zdnet.com.au.
17. Gardiner, B, ‘Agile pays off for Coates Hire’, CIO, 2 October 2014, www.cio.com.au/article/556482/
agile-pays-off-new-online-construction-portal/?fp=4&fpid=16.
18. ABC News Online 2012, ‘Anonymous Australia claims ASIO attack’, www.abc.net.au/news/2012-08-10/anonymous-
claims-asio-attack/4190874.html; Battersby, L & Grubb, B 2012, ‘Hackers cripple ASIO site to protest web spy plan’,
Sydney Morning Herald, www.smh.com.au/it-pro/security-it/hackers-cripple-asio-site-to-protest-web-spy-plan-20120810.
html; Dorling, P 2012, ‘Roxon puts web surveillance plans on ice’, Sydney Morning Herald, www.smh.com.au/technology/
technology-news/roxon-puts-web-surveillance-plans-on-ice-20120809-23x9l.html; McCormick, T 2013, ‘A short history of
hacktivism’, Canberra Times, www.canberratimes.com.au/it-pro/security-it/a-short-history-of-hacktivism-20130510.html; Wolf,
A 2012), ‘The future of hacktivism’, New Matilda, www.newmatilda.com/2012/11/13/future-hacktivism.
19. Lennon, N 2014, ‘Is your email ready for the summer bushfire season?’, ABC Technology + Games, 27 November.

ACKNOWLEDGEMENTS
Figure 1.2: © CPA Australia Ltd.
AIS Focus 1.2: © ‘Aided by referral bonuses, hospice industry booms’, Peter Waldman, Bloomberg
News, published in The Washington Post, 17 December 2011.
AIS Focus 1.4: © Nick Lennon.
Photo: © Konstantin Chagin / Shutterstock.

32 PART 1 Systems fundamentals

PART 2
Systems
characteristics and
considerations
In part 2 of the text we look at some of the issues to consider when designing the
operation of systems within the organisation, including the way systems will fit within
the structure of the organisation and its business processes, the way data is gathered
and managed within the processes and systems, the records of how the systems
operate, and the structures put in place to facilitate the smooth running of systems.

2 Business processes 34

3 Database concepts I 90

4 Database concepts II 135

5 Systems development 197

6 Technology concepts 238

7 Systems mapping and documentation 275

8 Internal controls I 330

9 Internal controls II 373

CHAPTER 2

Business processes
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

2.1 identify and interpret the components of organisational strategy and mission
2.2 critique alternative organisational structures, reflecting on their strengths and weaknesses and the
implications for organisational operations
2.3 identify and describe a business process
2.4 appraise the benefits of organisations adopting a business process perspective
2.5 critically evaluate the role enterprise resource planning (ERP) systems play in business process design
2.6 interpret and communicate issues for organisations changing to a process-based focus
2.7 summarise and evaluate approaches to changing business processes, in particular business process
re-engineering (BPR)
2.8 critically evaluate BPR techniques
2.9 critique the application of information technology (IT) to business processes by Australian firms.
Introduction
Do you remember what happened when you first enrolled as a new student on campus? Think back to some
of the different steps that were involved and the tasks that had to be performed for you to become an enrolled
student of the university. Initially, you probably received an offer via email with a link for you to complete
your enrolment online. While working through your online enrolment you would have completed sections
and forms related to FEE-HELP and various university records. These data would be shared electronically
with university staff for further processing. At the next stage you would have been photographed for your
student ID card and then forwarded on to another data entry point for receipt of a concession card. Then it
would have been off to the faculty for a meeting with a course adviser to discuss your subject enrolments for
the year. Finally, you would have entered your subject choices into the system, your student fees would have
been calculated, and then you would have needed to pay some or all of these fees online. On completion of
this you would be a fully-fledged student ready to commence your studies.
This is an example of a business process in action. The business process of enrolments within the
university environment is designed with the aim of enrolling new students as quickly and efficiently as
possible. It has a specific objective. What you may also note from this example is that there are several
different tasks that relate to different areas of the university involved in the completion of this process.
For a commercial enterprise the reality is no different. While the business processes that occur in the com-
mercial world may be different from those of enrolment, the underlying philosophy is the same. Business
processes lie at the heart of the modern-day organisation. As they have faced changing competitive environ-
ments over recent years, many organisations have realised that their business process can create a unique
competitive advantage, so they have looked closely at the assumptions and philosophies that embody their
design. This chapter explores some of these ideas in detail. We begin with a description of how an organ-
isation determines its objectives, which stem from its mission and strategy and drive the establishment of
business processes. We then look at the traditional hierarchical organisation, describing the advantages and
disadvantages that a hierarchical structure provides. This organisational structure is then compared to the
leaner model of the organisation, referred to as the process-based model. From this model is derived a defi-
nition of a business process. We then explore the benefits of adopting a business process perspective and
explain how business processes are central to the design of the modern organisation.

CHAPTER 2 Business processes 35

 Organisations changing from the hierarchical model to the process-based model, however, must
undergo organisational change. One approach for implementing such organisational change is to adopt
a process-based system, which leads to a discussion of enterprise resource planning (ERP) systems and
how they support the process perspective of the organisation, potentially contributing to the attainment
of a competitive advantage. From there, the discussion progresses to the concept of business process
re-engineering (BPR) as an approach for organisational change, and looks at some of the advantages and
disadvantages of BPR.

2.1 Organisational strategy and mission

LEARNING OBJECTIVE 2.1 Identify and interpret the components of organisational strategy and mission.
When organisations are created they will typically have a mission statement. The mission statement
usually contains an expression of the organisation’s vision, business domain, competencies and values.1
The vision makes a clear statement about what the organisation wants to be in the future, the busi-
ness domain is the area in which the business will operate, competencies express the business’s unique
strengths to be applied in the chosen domain, and values are the principles upon which the business will
operate.2 Examples of mission statements are contained in figures 2.13 and 2.2.4

Wiley mission
Wiley’s mission is to be a global information and education company providing content and services to
professionals, researchers, educators, students, lifelong learners, and consumers worldwide. Wiley is
dedicated to serving our customers’ needs while generating attractive intellectual and financial rewards
for all of our stakeholders — authors, customers, clients, colleagues, and shareholders.

FIGURE 2.1 Wiley mission statement

Google’s mission is to organize the world’s information and make it universally accessible and useful.

FIGURE 2.2 Google mission statement

You have probably heard the term ‘strategy’ used in a wide range of contexts. For example, sports
commentators and coaches will often talk about particular defensive or attacking strategies that allow
competing teams and individuals to overcome their opposition in a game. The essence of these sen-
timents reflects what strategy is all about — a choice about a course of action, a means of putting a
mission statement into practice. Within a business environment, strategy can be seen to operate at three
levels: (1) internal, (2) competitive and (3) business portfolio. Internal strategy relates to the decisions
that are made within the organisation; for example, organisational design and activities that are per-
formed (this will be discussed in more detail later in the chapter). Competitive strategy is concerned
with understanding the industry within which the organisation operates and distinguishing the organ-
isation within an industry. Business portfolio strategy operates at a broader level, looking at the decision
of which industry an organisation should compete within and how organisations can compete in new
industries. Information technology and the application of information systems can impact on each of
these strategy levels, which makes their discussion in an accounting information systems text extremely
relevant.5
Strategy determines how an organisation deals with its competitors, and what products it sells in what
markets and through what delivery method.6 Michael Porter, a well-known writer on strategy, suggests
that business really has two options when deciding on a strategy: (1) cost leadership or (2) differen-
tiation.7 A cost leadership strategy sees organisations carrying out their activities more cheaply than their

36 PART 2 Systems characteristics and considerations

competitors through economies of scale, technology, low overhead costs or efficient links with suppliers.
The alternative, the differentiation strategy, involves a business adding that little bit extra for customers,
offering unique products and services targeted to the customer’s needs. This higher degree of customer
attention and personalisation to meet customer demands allows the organisation to charge a higher price.
A contrast, albeit extreme, would be to compare a fast-food restaurant to a five-star restaurant. Both offer
meals, but there are obvious differences between the two when it comes to the personalisation of the pro-
vision of the meal, the service offered while dining and the overall ambience of the dining experience.
Essentially, Porter sees the implementation and attainment of these alternative strategies as requiring
attention to five elements of the business.8
1. Operational effectiveness. Effectiveness is about doing things better than your competitors, and doing
things correctly. For example, a machine on an assembly line for motor vehicles that is meant to place
four screws in the console but actually places three in position is ineffective because it is not doing
what it is meant to do.
2. Uniqueness. A business needs to choose activities that are different from those of the rest of the
market to distinguish itself from its rivals and gain a strategic advantage.
3. Trade-offs. The set of activities chosen by an organisation means it needs to make conscious choices
about the market it wishes to serve, the product or service it wishes to provide, or the particular
means of delivery of its product or service. By implicitly choosing what to do, an organisation is
simultaneously choosing what not to do.
4. Fit. This relates to how the different activities performed by an organisation combine to achieve a
common objective. The more the activities complement each other, the stronger the fit will be and the
more difficult it will be for a competitor to replicate them.
5. Sustainability. The more activities there are within a business and the greater the unity between the
objective and execution of these activities, the more difficult it will be for others to copy.
The perspective on strategy we have just discussed focuses on the organisation’s choice of activities.
This raises the question of how to go about this process. Once again, Porter has a model to help in
analysing the structure of an industry and identifying areas where an organisation can gain an advan-
tage. Porter argues that, for an organisation to distinguish itself from its competitors and succeed in
its industry, it needs to look beyond its internal functions to understand the five forces that shape the
industry in which it operates. These five forces are briefly described below.9
1. Rivalry among existing competitors. This refers to the current status within the market in which a
business operates. Competition between participants in the market can be intense due to competitors
developing new products, using marketing strategies and techniques, offering different levels of cus-
tomer service or offering lower prices.
2. Threat of substitute products or services. Substitute products or services are those that can be used as
an alternative to what the industry currently produces. As an example, shredded paper may be seen as
a substitute for polystyrene foam when packing goods in boxes.
3. Bargaining power of suppliers. A supplier of inputs to an organisation’s manufacturing or service
provision can find itself in a strong bargaining position if it is the only business able to provide a
particular product or service.
4. Bargaining power of buyers. This refers to the relative positioning of customers in their relationship
with the organisation. An organisation that provides to a small number of specialist customers can ill
afford to lose them; hence, the customer is in a position of relative strength.
5. Threat of new entrants. New organisations entering an industry alter the competitive dynamics of the
marketplace and create increased competition for the existing participants.
Using the five forces as a guide, an organisation can analyse its industry to identify particular oppor-
tunities or threats, and then develop tactics for these situations. For example, an organisation may
identify that the industry is made up of a large number of customers who are not particularly loyal to one
organisation. This may prompt the organisation to reconsider the activities it performs and the means of
interaction it has with customers in the hope that customers will develop an allegiance or loyalty to their

CHAPTER 2 Business processes 37

business. This could be done by introducing loyalty schemes or reward programs to encourage return
patronage and adding a cost for the customer who decides to shop elsewhere. AIS Focus 2.1 applies the
five forces approach to the ALDI supermarket chain.
An organisation’s choice about the set of activities to perform has been impacted greatly by the advent
of the internet and the emergence of e-commerce. The internet has led to new industries and new oppor-
tunities, for example, online auctions, digital markets for music and movies, and organisations that
acquire and compile data and customise it for user needs (aggregators), such as wotif.com for hotel
accommodation. (The aggregator example is discussed later in the chapter.)
The internet has also enabled organisations to reach a wider audience. However, that audience is
potentially better informed, since the internet provides a wide array of product information and buying
alternatives, which can lead to price pressure. Through the internet, businesses are also able to recon-
sider their choice of activities, better manage outsourcing and form partnerships more readily10 since the
internet is the ‘ideal tool for distributing and providing access to information’.11 Further, the integration
of activities within an organisation and between organisations is potentially more readily achieved
through the internet, due to its speed and its ability to link geographically remote places to make them
virtual neighbours. As an example, consider a traditional book publisher. Its conventional activities are
the writing, printing, warehousing and selling of books to customers through retail outlets. If we think
about the impact of the internet on these activities, stores like Amazon have potentially eliminated the
need for retail stores by having warehouses ready to send the books directly to the customer. An exten-
sion of this has been the introduction of the e-book which has eliminated the printing process entirely
through the delivery of books electronically. For publishers, this has meant a new set of activities in
book production and distribution.

AIS FOCUS 2.1

ALDI in the Australian supermarket industry

The Australian supermarket industry is dominated by Coles and Woolworths, which between them hold
around 75 per cent of the national grocery market.12 In 2001, the supermarket industry was affected
by the entry of the German-based supermarket chain ALDI. Starting with just one store in Australia,
ALDI has expanded to having more than 200 stores along Australia’s east coast13 and major distri-
bution centres in Melbourne and Sydney.14 ALDI sees itself as a discount supermarket chain, with the
equivalent of its mission statement stating that ‘Our philosophy still stands. All people, wherever they
live, should have the opportunity to buy everyday groceries of the highest quality at the lowest possible
price’.15
ALDI has established itself in the supermarket industry and now attracts more than 1 million cus-
tomers each week. Sales revenue estimates for ALDI have been around $2 billion.16 This raises the
question of how ALDI has been able to survive and thrive in the Australian supermarket industry, given
the domination of the two existing participants, Coles and Woolworths.
An application of some of Porter’s five forces to ALDI yield the following observations.
• Position of suppliers. The shortage of shelf space available in the large supermarket chains meant
that ALDI could create opportunities for suppliers to get their products on shelves.17 This would
have been seen as a strength in negotiating with suppliers and would have provided ALDI with a
potential means of locking in suppliers. Clearly, Aldi has gained some pull with their suppliers, as
is evident from their announcement in April 2011 that all their products would no longer contain
colour additives.18
• Position of customers. ALDI was seen by consumers as a substitute provider of their staple prod-
ucts. The cheaper, smaller shopping experience was one way of attracting customers. The quality
of products at a cheaper price (as a result of the no brand-name effect) was another. Some cus-
tomers were also looking for a change from the traditional supermarket duopoly.19 ALDI has tried
to position itself positively with customers by offering food products that do not contain food
colourings or additives, in response to concerns that some additives may have harmful effects on
children.20

38 PART 2 Systems characteristics and considerations

 • Threat of new entrants. With the supermarket industry dominated by the two main chains that
had existing relationships with suppliers and customers, ALDI’s entry could have been a chal-
lenge for the company. However, ALDI’s simple model has seen it establish a presence and
operate as a viable competitor. New entrants to the supermarket industry face the challenge of
building supplier and customer relations as well as acquiring the necessary space to establish
stores.21
• Threat of substitutes. ALDI could be a substitute for the larger stores, just as convenience stores
could be seen as a substitute. However, convenience stores are probably not a long-term threat, due
to their tendency to carry brand-name products and charge higher prices.22
• Overall industry position. The supermarket industry has traditionally been dominated by the two large
chains that have well-established technology, physical infrastructure and relationships with suppliers.
ALDI has established a viable presence in this duopoly market.
ALDI has operationalised its strategy through:
1. Smaller number of staff — multiskilled staff who can complete the range of responsibilities in-store,
which keeps overhead costs down.
2. Smaller number of suppliers and range of products — ALDI has made a conscious choice about its
suppliers, typically choosing non-branded or private labels, which allows it to offer the products at
30 to 40 per cent cheaper than branded products.23 On average, ALDI carries 900 different prod-
ucts in its stores, in contrast to what is reported as the ‘tens of thousands’ carried by Coles and
Woolworths.24
3. Smaller shopping premises — the smaller range of products enables costs to be kept down; for
instance, the size of ALDI’s stores is somewhere around one-fifth of the size of the typical Wool-
worths or Coles store. The activities have also been customised to support the adopted strategy,
with ‘no marketing department, no advertising department, no legal department and no human
resources department’.25
4. Simple in-store processes with a no add-ons approach — even the customer experience in the store
reminds us that this is a store operating leanly; customers need to buy their shopping bags and pack
their shopping after making a purchase.
5. Quality products at cheap prices — allows for built-in features, such as being able to go to the
ALDI website and see the price for all items they sell (it is thought that this will be prohibitive as the
product range increases to the level of the larger retailers).26
The processes and activities — from the smaller number of suppliers and products to smaller prem-
ises and smaller overhead costs — mean that ALDI has been able to build a tight fit in its activities that
has allowed it to fulfil its chosen strategy.

2.2 Organisational design

LEARNING OBJECTIVE 2.2 Critique alternative organisational structures, reflecting on their strengths
and weaknesses and the implications for organisational operations.
An organisation is an organised body or system. In a commerce context, an organisation is the business
enterprise, for example, Qantas, Telstra or Ernst & Young. These enterprises have mission statements
and adopted strategies, with the challenge being the implementation of these in practice. In order to suc-
cessfully implement their chosen strategy, organisations will consider the issue of organisational design.
In this section, we discuss and compare different types of organisational design.
Business enterprises organise themselves in different ways — that is, by adopting different methods
of providing a structure for their operations and coordinating the efforts of their employees so that
they work towards a common purpose. This common purpose should be reflected in the organisation’s
mission statement. As discussed earlier, the mission statement outlines the reasons for the company’s
existence, where it sees itself as making a contribution, and what its aims and objectives are.
One technique to organise a business enterprise is through its internal organisational design (also
called organisational structure or hierarchy) — the structure of the relationships, resource allocation,

CHAPTER 2 Business processes 39

interactions and reporting responsibilities among staff. Over the years, organisations have adopted a
range of organisational designs. We will discuss two approaches: the functional perspective and the busi-
ness process perspective. Both have advantages and disadvantages for the organisation, and the different
contexts in which a business may operate will dictate a different structure. This text focuses on the busi-
ness process perspective, but you should also be familiar with the more historical functional perspective,
from which the business process perspective emerged.

The functional perspective of the organisation

Analysis of well-established organisations often reveals a very hierarchical design. A hierarchically
designed organisation, or the functional perspective of the organisation, is one with clear organisational
structures in place, including functional divisions and reporting responsibilities within and among these
functions clearly defined.
An early management writer, Frederick Taylor, developed a management philosophy that was referred
to as scientific management.27 Typical of the hierarchical, manual labour and control-based environ-
ment of the time, Taylor proposed that employee tasks and responsibilities should be clearly specified,
with each employee having a defined role. A range of employees would collectively perform a range
of tasks, but each individual employee would perform only a small variety of tasks. Thus, employees
would develop a specific skill-set and become specialists in this narrow area. The implementation of
Taylor’s ideas within the organisation led to the creation of hierarchies, with employees supervised
by middle management, who reported to top management. Because of the nature of each employee’s
role — clearly defined, highly specific and structured — each employee was largely unaware of what
others did.
This management philosophy, primarily geared at the individual level of work design, also infil-
trated the organisational level, with organisations frequently designed and departmentalised based
on the different functions performed. A business function or department is a specific subset of the
organisation that performs a particular role that contributes to the organisation achieving its objec-
tives. Examples of business functions or departments include the sales department, responsible
for selling products or services, the manufacturing department, responsible for making goods, the
accounting department, responsible for keeping records of the organisation’s financial activities, and
so on. Notice how the function of each department is specifically defined, with minimal overlaps to
other functions.
This structure is represented in figure 2.3, which contains a hierarchy for a typical functionally based
organisation.
In the organisation depicted in figure 2.3, there are five functional areas or departments: logistics,
production, accounting, sales and human resources. Each performs a specific function within the organ-
isation. Notice how the organisation is divided into three levels: strategic management, management
control and operational control. This division, developed by Anthony, is a way of classifying the dif-
ferent nature of tasks in different levels of the organisation.28 At the operational level, the concern
is to complete the tasks in the functional areas or departments in a proper manner. This will include
those actually performing the tasks and those who supervise the performance of the tasks. Above this
is the management control level, responsible for monitoring the performance of the different functional
areas. In this case, two of the departments (logistics and production) report to one manager, while the
remaining three departments (accounting, sales and human resources) report to a second manager. These
managers will synthesise information about the performance of the departments under their control and
forward this to a higher level of management, labelled the strategic level. The strategic level is con-
cerned with developing strategies for business success and coming up with an appropriate mission for
the organisation. Such tasks are completed based on an analysis of the performance information that
filters up from the management control level, as well as through the strategic management’s analysis of
the external environment.

40 PART 2 Systems characteristics and considerations

 STRATEGIC MANAGEMENT

MANAGEMENT CONTROL

LOGISTICS

PRODUCTION

ACCOUNTING

SALES

HR
OPERATIONAL
CONTROL

FIGURE 2.3 A functionally based organisation

Source: Based on Sandoe, Corbitt & Boykin 2001.29

It is notable that communication across the departments does not occur below a high level in the
organisation. To share information throughout the organisation, it must first be sent up and then across
the hierarchy before it filters down to lower levels. In addition, completing a task often requires work
handovers between various departments that inevitably create delays, bottlenecks and information gaps.
The practical reality for many organisations today is that this is an unworkable business model. Some
have chosen to flatten their organisation by removing some layers within a department. In the process
of flattening the organisation, some have adopted a business process perspective. Business processes are
discussed in the following section.

Benefits
There were, and still are, many arguments for pursuing a functionally based organisational design.
These include strong control and coordination, stability and task specificity that can be built into the
organisation.
•• Control and coordination. One strong benefit of the functional perspective is that it provides a great
deal of organisational control. Due to the high volume of reporting relationships that exist — for
example, operational staff in each department report to department managers, who report to managers
at the management control level, who report to managers at the strategic level — there is a strong
monitoring network. Of course, the disadvantage is the bureaucracy required to support such a
structure. This is discussed later in the chapter.
•• Specificity. As we mentioned previously, tasks within the functionally based organisation will be
highly defined and specified. This means employees and managers are clear on what their tasks
and responsibilities are. The functional structure provides a delineation of tasks across different
departments of the organisation, as well as within departments. This can be a useful tool for an
organisation wishing to gain clarity and specificity of employee roles and responsibilities.

CHAPTER 2 Business processes 41

Problems and limitations
For each of these advantages, there are disadvantages or limitations to the functional perspective. It
does not necessarily reflect the reality of today, can lead to information and communication problems
or a focus on the wrong things, and can result in the organisation lagging behind when reacting to the
environment.30
•• Not reflective of the reality of today. Businesses today need to be driven by customer needs, rather
than by the best way to control operations within the organisation. It is often difficult to provide
customer service through a hierarchically and departmentally based organisational design that suffers
from poor communication across the organisation where it possibly matters most.
•• Information and communication problems. The functional perspective can create an overly hierarchical
and bureaucratic organisation. A common consequence of this is the perception that ‘staff create
overheads and bureaucracies that far exceed their value’.31 Take, for example, a loans consultant
working on loan applications in a bank. The consultant may process a particular part of the loan
application; for example, the credit check. In an extremely hierarchical organisation, the consultant
would conduct the credit check and forward the result to a supervisor, who would then make a decision
on the creditworthiness of the applicant and send this back to the consultant, who would then pass on
the decision to the next person involved in handling the application.
•• Slow to react to the environment. The hierarchical and bureaucratic nature of the functional
organisation means it can be slow to react to changes in both the internal organisational environment
and the external operating environment. It takes time for information to filter up and down in the
organisation. That is, if strategic management decides upon a new strategy, it must be communicated
to the management control level. These middle managers then need to communicate the strategy to
the operational managers, who then need to communicate it to the operational staff performing tasks
in a different department. This makes the organisation extremely slow and clumsy in responding to
change. Similarly, in the reverse, it takes time for information to flow up the organisation, meaning
there will be delays between when something is reported at the operational level and when it can be
addressed at the strategic level.
•• Focuses on the wrong things. As Byrne so eloquently states, functionally based organisations are built
around the idea that staff should ‘look up to bosses instead of out to customers’.32 The managers and
employees scattered throughout the organisational hierarchy in figure 2.3 will be solely concerned with
pleasing their immediate supervisor. This comes about due to the precisely defined task specifications
and the hierarchy and monitoring network that is superimposed on this type of organisation. However,
as can be seen in the following sections, focusing on reporting hierarchies can be dangerous for an
organisation because it can lead to an ignorance of customer requirements.
These disadvantages led to an alternative organisational design: the business process perspective.

2.3 What is a business process?

LEARNING OBJECTIVE 2.3 Identify and describe a business process.
A business process is a series of interlocking activities that work together, across the organisation, to
achieve some predetermined organisational goal. This predetermined goal is typically defined around sat-
isfying customer needs. Look at the definition of a business process presented above. You should note that
four key aspects of this definition have been italicised: ‘interlocking activities’, ‘across the organisation’,
‘predetermined organisational goal’, and ‘customer needs’. Each of these aspects will now be discussed in
more detail, enabling you to gain a comprehensive understanding of what a business process is.

Interlocking activities
A business function was defined above as a specific subset of the organisation that is designed to
perform a particular task that contributes to the organisation achieving its objectives. In a business

42 PART 2 Systems characteristics and considerations

process, various business functions are involved in a series of interactions with one another to
provide a good or service for the end customer. Thus, the nature of a business process is such that
business functions are integrated and work together to complete a predefined sequence of tasks and
activities.

Across the organisation (the horizontal perspective)

In the hierarchical structure in the functional perspective, information flows are vertical. However, the
practical reality is that flows occur across an organisation. These horizontal flows are representative
of business processes and reflect that different departments and functional areas need to communi-
cate with each other to provide the good or service a customer may require. As a practical example,
consider what may happen in a retail organisation when it makes a sale to a customer. The sales staff
will process the customer’s order and enter it into their sales system. Once the order is captured they
check for availability of the goods, since any stock that is unavailable may need to be placed on
back-order. If items are out of stock, this out-of-stock notification may be sent to the manufacturing
division, so that more units can be produced. After collection from the warehouse, the goods will be
forwarded to the shipping department for distribution to the customer. In the process of making the
sale to the customer there has been a role for the sales department and several other functional areas
in the organisation. This is the true nature of a business process, with flows occurring across the
organisation.

Predetermined goal
Business processes are designed to achieve some predetermined goal or objective of the organisation.
Thinking of some typical business processes, you can intuitively identify the predetermined goal they
are designed to achieve. For example, the sales process aims to make and capture sales from customers,
and the purchasing process aims to acquire goods from suppliers and keep order costs and inventory
carrying costs to a minimum.

Customer needs
The objective of a business process is to achieve an organisational goal, which is typically geared to the
needs of a customer.
Figure 2.4 illustrates an example of the process perspective for a sales process. A quick explanation
may help in understanding the definition of a business process. A sales process is designed with the
aim of selling goods and delivering them to customers. Assume that a mobile salesperson visits cus-
tomer sites and canvasses products that customers may require. If a customer wishes to make a purchase,
the sales representative remotely logs on to the office network and accesses inventory information to
check that the goods are in stock and ready to be delivered. Before approving a sale, the sales represen-
tative will also want to confirm that the customer does not have a history of bad debts. So he or she
might check with the accounts receivable department for a quick credit rating. Once inventory avail-
ability and creditworthiness are confirmed, the sales representative will approve the sale and send details
to the logistics department. The logistics department will arrange for delivery of the goods to the cus-
tomer. Finally, since the sales representative is paid on commission, details of the sale will be sent to
human resources so that the commission attached to the sale can be calculated.
Notice how, in carrying out the sales process, information was required from across the organisation.
The process perspective designs organisations around this principle, making sure that interaction and
coordination are present so that information is readily accessible. Also notice how much of the cus­
tomer’s interaction with the organisation is through the sales representative. The reduced hierarchy in
the process organisation, with flows across the organisation at lower levels, allows the process to be
completed quickly and efficiently.

CHAPTER 2 Business processes 43

 HR
SALES

PRODUCTION

ACCOUNTING

LOGISTICS
SALES PROCESS

FIGURE 2.4 A process-based organisation33

What is a business process compared with a

business function?
To appreciate the remainder of this chapter, you should be clear on the distinction between a business
process and a business function. Recall that a business process was defined as a series of interlocking
activities that work together across the organisation to achieve some predetermined organisational goal
that is typically defined around satisfying customer needs. A business function was defined as a specific
subset of the organisation that performs a particular role that contributes to the organisation achieving its
objectives. Notice the differences in these definitions. A business function is a specific task or role that
is performed; for example, accounting, sales or marketing. Moving from business function to business
process shifts the frame of reference from looking at specific individual functions to how these functions
interact with one another to deliver a good or service to the customer. So, the business process is a com-
bination of business functions operating together to achieve a goal.
A summary of the distinctions between the process and functional perspective is contained in table 2.1.

TABLE 2.1 Functional versus process perspective

Functional perspective Process perspective
Focus What is done — e.g. accounting, sales, How it is done
logistics
Orientation Vertical, hierarchical Horizontal, across the organisation
Objective Task driven Customer driven
Personnel Specialists perform highly defined tasks Generalists perform tasks across the process
Source: Based on Sandoe, Corbitt & Boykin 2001.34

44 PART 2 Systems characteristics and considerations

Business processes within the organisation
Business processes are the key to any organisation. Businesses operate best when there are clearly
defined processes that can be followed, with examples including processes to order raw materials
within a manufacturing firm, manufacture products, sell products to customers, handle customer
enquiries and hire new employees. Each of these broad processes will be an integral part of an organ-
isation, because, for example, without the manufacturing process the organisation has no goods to
sell, and without the purchasing process the organisation has no raw materials to convert into finished
goods.

Examples
Some typical examples of business processes are the sales process and the purchasing process. A brief
discussion of their operation is now provided, including their general aims, the participants involved, and
their inputs and outputs. For a more detailed discussion, refer to chapters 10 to 12.
Sales
Aim: To sell goods to the customer and collect cash from sales.
Participants: Sales staff, customer, billing staff, warehouse.
Inputs: Sales order.
Outputs: Invoice, receipt, shipping document.
Purchasing
Aim: To acquire goods from suppliers and manage stock in order to sell to customers and avoid
stock-outs.
Participants: Warehouse staff, purchasing staff, sales staff, vendor.
Inputs: Purchase requisition, back-order.
Outputs: Purchase order.

2.4 Why business processes?

LEARNING OBJECTIVE 2.4 Appraise the benefits of organisations adopting a business process
perspective.
There are several reasons for adopting a business process perspective within the organisation, one of
which is the resource benefits that flow from having a process emphasis. This comes about because
the process perspective offers an organisation a more coordinated and integrated approach, reducing
wasted time due to rework, bureaucracy and administration. This becomes evident in exploring the
IBM Credit discussion later in the chapter and seeing some of the benefits that were realised by
shifting from a functional to a process-based design. Toyota is another example of a company that
was able to realise significant benefits by introducing a process focus into its vehicle manufacturing
operations.35
The business process perspective can yield benefits for an organisation through improved customer
service and customer relations, a value-adding emphasis and, potentially, a competitive advantage.
Business processes are typically built around the desired product or result that is to be achieved. More
often than not this will be based around the customer, whether inside or outside the organisation.
As a result, customer satisfaction, attention and service are potentially higher in a process-focused
organisation.
The process perspective can also lead to the better use of resources. As is discussed in the section
that examines ERP systems and business processes, business processes can eliminate duplication of data
and wastage in storage and can also restructure ineffective interdepartmental communication networks.
This can lead to better information flows through the organisation, potentially leading to more effective
decision making by management.

CHAPTER 2 Business processes 45

 In the functional perspective of the organisation, the complex and well-developed hierarchies intro-
duce bureaucracy and can lead to the creation of jobs and functions that do not add any value to the
goods or services provided by the organisation but are necessary to support the bureaucracy. In the
process perspective, a flattened organisational design can reduce bureaucracy and create a more flexible
organisation. Part of this flattening will involve identifying tasks and functions that do not add value and
eliminating them — after all, if they cost resources to perform but do not give anything in return, why
bother doing them in the first place? A well-structured business process will have minimal non-value-
adding activities included in its design.
Business processes can also provide an organisation with a competitive advantage, with organisations
increasingly looking towards the design of their business processes as a means of distinguishing them-
selves from the host of competitors they may face in their industry.36 This competitive advantage comes
from the design of business processes that are unique or offer something different. For example, a com-
pany may design its manufacturing process to enable it to offer a high degree of customisation in the
products that consumers purchase, or build in added customer service features, which could distinguish
the company from its competitors. The issue of the design of business processes, ERP systems and com-
petitive advantage is further discussed later in the chapter.
It was mentioned earlier that a business process consists of a series of interlocking activities that work
together to achieve an organisational goal. We also mentioned that business processes can be outsourced.
The outsourcing of part or all of a business process is something that has increased in prevalence as the
impact of technology is progressively felt across the world.
In his book The World is Flat, Thomas Friedman37 describes a series of events that he sees as
having flattened the world, reducing international boundaries for commercial communication
and collaboration. The common theme in Friedman’s discussion is that technology has had a sig-
nificant role in ‘flattening’ the world, allowing the distribution of activities across the globe, with
this distribution appearing seamless to the end customer. For businesses this is significant, since it
allows them to outsource offshore parts of their business process with relative ease, with the real-
isation of benefits such as potential cost savings and better performing processes. The increased
role of technology in business processes has made outsourcing beyond our shores a reality for
many organisations, with the worldwide outsourcing market estimated to be worth in excess of
US$300 billion.38
Common examples of outsourcing of parts of business processes include the operation of a call
centre for customer enquiries, and the maintenance of IT requirements — including software design and
development — in remote locations. This is reflective, in part, of the modular nature of a business pro-
cess, and also of the role that information technology is playing within the design of business processes.
Friedman’s notion of a flattened world is evident in the higher levels of technology integration that have
enabled global communication to occur in a seamless manner. Such technological integration enables
a customer to seamlessly deal with a call centre operating from India without even being aware of the
thousands of kilometres between them and the assistant on the other end of the line. To further enhance
the seamless nature of this process, many call centres train their employees in the accent and phonetics
of the customers they will be dealing with, to the extent that they even adopt anglicised names when
dealing with customers!39
One benefit derived from outsourcing part of a business process is cost savings, with many
international destinations offering equivalent services for less cost, particularly in labour, than
that in Australia. Of course, this approach can also create social and ethical issues that need to be
considered when making the outsourcing decision, particularly the nature of the conditions that
overseas workers encounter. More generally, outsourcing part or all of a business process allows
a company to ‘take layers of cost out of its operating structure in order to return more profits to
shareholders.’40
AIS Focus 2.2 describes the rationale and also some of the issues for businesses that are looking to
outsource some or all of their business process.

46 PART 2 Systems characteristics and considerations

 AIS FOCUS 2.2

Outsourcing business processes for innovation

Many companies look to business-process outsourcing to save money. But the most successful clients
concentrate less on cost savings and more on achieving innovation.
In recent years the number of companies that outsource critical business processes to out-
side suppliers has grown significantly worldwide. The business-process outsourcing (BPO) market
has been estimated to be worth $309 billion in 2012, including activities such as finance and
accounting, human resource management, procurement and legal services, and the overall volume is
estimated to be growing at a rate of around 25 per cent annually. Many organisations initiated BPO
as part of an operational effort (for example, to reduce costs or access skills), but it has evolved into
much more.
Senior managers today expect more from BPO service providers than short-term cost savings and
meeting minimum contractual requirements. Moreover, they are sceptical of big-bang improvements.
Companies want service providers to innovate constantly. In relationships that companies classify as
high performing, the service providers perform a series of innovation projects that deliver substantial
long-term improvements to the client’s operating efficiency, business-process effectiveness and stra-
tegic performance. Consider the following examples.
• A BPO provider helped a health care company improve the claims adjudication process by using
analytics to predict claims likely to result in rework. The predictive tool now intercepts more than
50 per cent of claims that would have been reworked, saving the client $25 to $50 in administrative
costs per overpaid claim and $6 to $12 per underpaid claim.
• An aerospace manufacturer worked with its BPO provider to add new key performance indicators and
processes to manage third-party vendors. This allowed the client to improve customer-order fill rates
for new parts from 60 per cent to 85 per cent and turnaround times for delivering parts to grounded
vehicles from 21 hours to 17 hours.
• A supermarket chain collaborated successfully with its BPO provider to implement new fore-
casting tools, techniques and methods that improved the client’s stock fill rate from 80 per cent to
95 per cent, reduced inventory by 27 per cent and reduced error rates by 50 per cent.
These types of innovations are not automatic. Companies and service providers must work together
to foster innovation. Specifically, companies must motivate providers with incentives, and both par-
ties must nurture a collaborative culture that produces continuous waves of innovations within client
organisations, something we call ‘dynamic innovation’. For example, the supermarket chain cited above
worked with its BPO provider to complete a series of more than 50 continuous improvement projects
over the course of three years to achieve cost savings, faster product delivery times and higher fulfil-
ment rates.
A static view of BPO innovation would treat each individual innovation as incremental; a dynamic view
looks at how year-on-year programs accumulate to improve the client’s overall performance.41

The selection of processes to outsource is critical because an organisation would obviously be reluc-
tant to outsource a process that provided it with a competitive advantage. Outsourcing can also create
social, political and ethical issues for an organisation.

End-user perspective
Business processes are typically geared around the needs of the customer, inside or outside the organ­
i­sation. A common example of an external customer could be a client who purchases a product or service
from the organisation, while an example of an internal customer could be someone within the organ-
isation who uses the output of a particular process to perform his or her own task. An example of this
latter type of customer could be a purchasing manager who uses the outcome of the sales budgeting
and manufacturing scheduling process to determine what type and quantity of raw materials need to
be ordered.

CHAPTER 2 Business processes 47

2.5 ERP systems, business processes and best
practice
LEARNING OBJECTIVE 2.5 Critically evaluate the role enterprise resource planning (ERP) systems play
in business process design.
An ERP system is an integrated set of computer program modules that integrate the different functional
areas of the organisation. The key idea with an ERP system is that all application modules access a
single shared database, allowing ERP systems to instantaneously share data horizontally and vertically
within an organisation. A simple depiction of this key ERP concept is contained in figure 2.5.

Function-based information system ERP system

Sales Marketing Warehouse Sales

system system system system

Sales & Products & Inventory Sales, customer,

customer services Marketing Warehouse
data system products and system
data data services &
inventory data

FIGURE 2.5 Function-based system vs ERP system

The hierarchical structure of organisations designed around business functions create problems in that
they tend to be inadvertently developed around an information silo principle.
This leads each functional area of the organisation to develop its own information system to solve its
own function-based problems. For example, sales will develop its own systems to handle sales records
and customer sales orders, the warehouse division will develop its own systems for inventory manage-
ment, and marketing will develop unique systems for marketing products and services. More often than
not, these systems are developed in isolation, and each function will fail to consider how it fits in with
other departments. This can lead to duplication of data across the organisation, which creates its own
problems. The systems become like silos within the organisation — operating on their own with little
interaction.
While the idea of functionally based systems may seem logical — after all, one would assume that
those within a function know what they require a system to do, and are consequently best equipped to
develop their own system — it fails to recognise the realities that confront the modern organisation. As
organisations adopt the business process perspective, they also require information systems that recog-
nise and are designed around these realities.
ERP systems are a way for organisations to implement a system to overcome the information silos
of the functional approach and put into practice the philosophy of a process perspective. ERP systems
accomplish this by having a series of modules related to the different functional areas of an organ-
isation — for example, typical modules include sales, accounts receivable, inventory and purchasing.
However, unlike in the information silo approach, in an ERP system these modules are all part of one
package. As a result, the modules are integrated and able to operate efficiently. For example, when a
sale is entered into the sales module, the inventory data will be updated to record the commitment of
goods, and accounts receivable will be updated to reflect the new outstanding balance of the customer.
This integration more accurately reflects the reality of a process-driven organisation. Additionally, all

48 PART 2 Systems characteristics and considerations

modules will operate from a single shared database central to the ERP system. As a result, data sharing
is enhanced and the problems of data duplication and redundancy are resolved.
Additionally, the design philosophy of ERP systems is centred on the idea of best practice. The
business process workflows supported by an ERP system have been designed and programmed into
the system based on what is deemed to be, following research and investigation, the best way to
perform them. These standards of best practice are one of the compelling reasons for organisations
to adopt ERP systems as they are and not change the software. After all, why would you change
something that is the best design? However, this necessitates thinking about some of the situations
in which a business may want to adopt a business process but not how it is configured in an ERP
system.
Davenport describes some of the scenarios where businesses are better off changing an ERP package
rather than changing their existing business processes.42 Conventional wisdom says that an organisation
is best to adopt an ERP system as is, rather than change it, for two reasons. The first is that the system
represents best practice for a process. The second is that the cost of an ERP system, without modifying
it, can be enormous (maybe millions of dollars). Once you start altering and modifying the design of the
system, these costs rise rather rapidly. Altering an ERP system can be a very costly process for an organ-
isation. On their own, these two arguments are reasonably compelling reasons for changing the organ-
isation and its processes to suit the system. However, there is one critical factor to understand before
doing so: competitive advantage.
The aim of any organisation is to gain some form of competitive advantage over its competitors. A
competitive advantage is something unique that a business does that is not offered by its competitors and
thus represents a way for the organisation to distinguish itself from the rest of the field. One way for an
organisation to do this can be through the configuration of its business processes. As an example, a retail
company may configure its sales and support process to offer total customer service and support that
none of its competitors are able to match, allowing it to keep existing customers and attract new ones.
The retail firm would most probably be extremely unwilling to adjust this process, as long as it remained
unique, since it would be one of the ways it distinguishes itself from its competitors. So for it to adopt
an ERP system, with its standardised business processes, would not make sense. This is because the pro-
cesses embodied in the way the organisation currently operates would most probably not be embodied
in the design of the ERP system, and adopting the ERP system would mean giving up its uniqueness in
the marketplace.
So organisations designing business processes and considering the adoption of ERP systems need to
carefully consider their existing business practices, how they provide a competitive advantage, and how
the business processes represented in an ERP system will fit or conflict with them. The aspect of homo-
geneity can also be a reason not to configure a business process around an ERP system; after all, the
ERP system and its processes are available to every organisation willing to pay for it. If all organisations
adopt the software and have the same underlying processes, how can they distinguish themselves and
gain a competitive advantage?
Volkoff describes the example of a photographic company that was adopting an ERP package
throughout its organisation.43 Having already adapted to some of the modules, the time came to apply
the sales and marketing module within the organisation. What the organisation found was that by
adopting the module, thus changing the organisation to suit the design of the system, it would lose some
of its uniqueness. This was because, up until the adoption of the ERP system, the company’s sales and
marketing process had been designed to allow a great deal of flexibility and customisation in the sales
representatives’ duties. As a consequence, the representatives were able to tailor prices and packages to
individual customers, as well as handle back orders and delivery of goods. The organisation found that
by blindly adopting the ERP package a lot of these ‘customer friendly’ aspects would be lost as they
were replaced by the generic processes designed into the software. Alternatively, because of the vast
array of options that were used by sales representatives when dealing with customers, the prospect of
configuring the ERP system to accommodate these was a daunting, if not unrealistic, task.

CHAPTER 2 Business processes 49

 Porter alludes to this idea when he mentions that strategy and competitive advantage are all about
choosing to do the activities in a business process differently from competitors. If all your competitors
are adopting ERP systems, then perhaps keeping your existing business processes can be a way for you
to distinguish your organisation. At the very least, in the short term, it might be possible to provide pro-
cesses at a lower cost than competitors, because you do not have the large overhead associated with the
acquisition and installation of an ERP system.44
On the other hand, those adopting ERP systems may be able to design faster, more efficient business
processes, benefiting from the centralised database, lack of duplication, integration and business process
perspective that an ERP system provides. One benefit that could be available from an ERP system, par-
ticularly through integration, is that the performance of customer service-based processes could improve.
Think about how many times you have rung a business, asked a question, received an answer, asked
a second question and been told, ‘I’m sorry, I can’t answer that question, I will need to transfer you
through to the accounts department.’ This is symptomatic of a functional organisation with its infor-
mation silo design. The integration of functions through ERP systems means that, potentially, one
person, a customer service representative for example, can handle all customer enquiries, from sales
orders to order status, to accounts owing details, to returns and complaints. The integration of data in
ERP systems allows organisations to build the information into the business processes, with the benefit
flowing on to the customers of that process.

2.6 Issues in moving to a business process-based

environment
LEARNING OBJECTIVE 2.6 Interpret and communicate issues for organisations changing to a process-
based focus.
There are often many issues that need to be addressed and managed for organisations that shift from the
functional information silo approach to the business process approach. These include changes in the role
of management and in the design of employee tasks and responsibilities.

Management change
The first stage in adopting a business process perspective is that it must be represented in the design
of the organisation. There is little point to an organisation saying ‘we are committed to a business
process perspective’ and then in the same breath saying ‘we are maintaining our functionally based
structure’. The result would be that the organisation’s purported commitment to processes will prob-
ably fade away as just another management fad and the status quo of the functional approach will
quickly be restored.
How the organisation is managed must change if the change in perspective is to be taken seriously.
As with most things associated with change, support needs to come from the top down. But the reality
for some organisations can be that the change at the top is difficult. As Hammer and Stanton observe:45
[T]he power in most companies still resides in vertical units — sometimes focused on regions, some-
times on products, sometimes on functions — and those fiefdoms still jealously guard their turf, their
people and their resources . . . the horizontal processes pull people in one direction; the traditional ver-
tical [functional] management systems pull them in another.
Why does management act like this? The answer lies in the effect of a business process perspective on
roles and responsibilities within the organisation. Shifting to a process-based organisation can mean sig-
nificant changes in the way people perform their duties. What was once a traditional, narrowly defined
specialist job can become a generalist and diverse role. This pushes the rights to decision making further
down in the organisation’s hierarchy. As a result, there can be a power shift in the organisation, with the
middle layers of management resisting such changes to their responsibilities.

50 PART 2 Systems characteristics and considerations

 Hammer and Stanton46 describe the example of Texas Instruments, a manufacturer of calculators and
electronic products, and some of the management issues it had in shifting to a process-based perspective
for its product development. Those who were entrenched in the functional perspective of the organ-
isation refused to cooperate with the process-based push, with the resistance resulting in some functional
managers refusing to release staff, resources and authority to those on the new process teams. This can
be seen as reflective of management’s resistance to the change, as well as the process focuses being
implemented within what was ostensibly still a functional firm: the power and authority for the running
of the organisation still rested with the functional departments.

People change
A shift to a process perspective has the effect of breaking down functional barriers and divisions that
previously existed. The person in the accounts department is no longer concerned solely with doing the
accounting job, but rather doing it so that it integrates with the rest of the business process. The focus
shifts beyond the traditional and narrowly defined duties associated with the functional perspective of
the organisation. This can lead to increased authority for those lower in the organisation, as well as a
more stimulating work environment. Instead of turning up to work knowing that all they will be doing
is one specific, narrowly defined task, as is generally the case in the functional environment, employees
become involved in a range of tasks across the process and see how the tasks integrate with each other.
This creates a much more stimulating environment for the employees.
Pursuing a process focus can often mean shedding a layer of middle management, as the organisation
looks for value-adding activities and the removal of non-value-adding activities and functions. As you
would logically expect, this can create a degree of resistance among those threatened by the change for
two reasons. First, the manager may face redundancy, which is not an enticing prospect. Second, the
manager may face a change in roles and responsibilities and, possibly, the loss of some authority.

2.7 Changing business processes

LEARNING OBJECTIVE 2.7 Summarise and evaluate approaches to changing business processes, in
particular business process re-engineering (BPR).
Business processes are neither static nor concrete. Indeed, they should be viewed as being in a con-
stant state of flux, as the impacts of new technologies, competition and general changes in the business
environment all have an impact on how organisations choose to design their business processes. The
means of changing processes is referred to as business process redesign, with several variants available
to an organisation undergoing change. One approach is what is referred to as Total Quality Management
(TQM), the second alternative is business process re-engineering, and the third approach is a combi-
nation of these approaches, otherwise known as an eclectic approach.47

Total Quality Management (TQM)

Total Quality Management (TQM) is a progressive approach to organisational change that works on the
principle that a series of small progressive steps is the best way to improve operations. The philosophy of
TQM is geared around four main concepts: quality, people, organisations and the role of management.48 The
TQM approach dates back to the 1950s, with numerous versions or approaches being developed since then.
The most commonly encountered current TQM approaches are Six Sigma and Lean Manufacturing. In this
we use the generic term TQM when discussing this incremental approach to process redesign.

Quality
The assumption relating to quality is that the costs of poor quality, as represented through the costs
involved with rework and product returns, are greater than the costs associated with developing and
refining business processes to generate high-quality output. This idea makes sense if one adopts a

CHAPTER 2 Business processes 51

long-term perspective for the organisation. While in the short term it may be possible to cut corners and
not worry about quality in processes, in the long term this will generate faulty or defective outputs that
will ultimately be rejected by customers. If customers leave the organisation, then ultimately the organ-
isation will go out of business.
People
The people aspect of TQM refers to how people within the organisation are valued for both their con-
tributions towards the process and their ideas about how the process can be improved. People within the
organisation need to be encouraged to provide feedback about the design of a process — particularly at
the lower levels of the organisation — since it is often these people who have the best understanding of
how the process really operates, because they work as a part of it every day. There are many examples
where this inclusive approach towards the thoughts and ideas of lower-level employees has reaped
numerous benefits for an organisation when redesigning its processes. An example of this is the Toyota
motor company, which designed its own processes rather than adopting American techniques, and in the
process built in employee creativity and innovation, which led to higher output and productivity levels.49
Organisations
The organisational aspect of TQM essentially refers back to the earlier discussion of business processes
and the process-based organisation. It emphasises that the organisation does not operate as a series of
independent departments but rather that functions interact to provide a good or deliver a service. This
presents some issues for the organisation that is looking to improve its processes because it requires rep-
resentatives from all the functions involved in a process to be involved. There is little point having only
the sales department involved in improving the sales process because this ignores the reality that the
accounts receivable, warehouse, manufacturing and marketing departments are also potentially involved
in the process of selling goods.
Management
Finally, TQM asserts that change and improvement can only occur if they have the support and endorse-
ment of top management. After all, it is the top management of an organisation that designs the struc-
ture of the business and the processes that occur. So TQM requires management to focus on processes,
rather than individual functions, and provide strong guidance and support for change efforts. A big part
of providing this guidance and support is nurturing an environment where employees are encouraged to
comment and provide feedback on the performance of existing processes, as well as on how they can
be improved. Management does not perform the process in a hands-on way — the employees who do
so are the best source of ideas about improvements. Additionally, involving employees in the generation
of ideas for process improvement can help to increase the acceptance of the change when it is actually
implemented.
Another critical aspect of the TQM process is that, potentially, ideas for change and improvements
to a process can be driven through the organisation from the bottom up. That is, ideas from the fac-
tory floor can be filtered up to top management for official approval, and then put into place within the
organisation. The impetus for change and improvement comes from the initial ideas of the lower-level
employees in the organisation. By comparison, as is seen in the following section, BPR is more of a top-
down approach to process improvement.

Business process re-engineering (BPR)

Many of the large organisations in operation today were first designed decades ago. As a result, they will
typically have a very hierarchical structure, remnants of an era when organisational control and reporting
hierarchies were the priority, instead of business processes and customer services. Increasingly, they
are being confronted with the need to redesign their operations, shifting from processes built around
the organisational hierarchy to a newer process-based organisation. Business process re-engineering
(BPR) is one approach to this redesign.

52 PART 2 Systems characteristics and considerations

 Hammer and Champy, in one of the key reference texts on the topic of BPR, define it as ‘the fun-
damental rethinking and radical redesign of business processes to achieve dramatic improvements in
critical contemporary measures of performance, such as cost, quality, service, and speed’.50 They then
go on to emphasise four key components of this definition, these being fundamental, radical, dramatic
and process. These four components will now be discussed, including aspects of their importance to
BPR and their practical relevance to organisations.
•• The fundamental aspect of the BPR definition forces an organisation to question what activities it
performs as a part of its current process. It is aimed at looking at what takes place in the current
system and questioning whether it is really needed.
•• The radical component of the definition essentially compels organisations to start again, discard what
already exists and redesign from scratch. Also known as the clean slate approach, its objective is to
encourage thoughts about new ways that a process could be performed, rather than just tinkering at
the edges of existing approaches.
•• If an organisation undergoes a BPR effort, it is looking for a dramatic return or improvement, especially
when the risk and cost of a BPR project are considered. Therefore, BPR is aimed at achieving large
improvements in the key performance indicators that an organisation uses.
•• The process aspect, reflected by its appearing in the name of the concept, is central to BPR. The thrust
is that organisations must forget about functional perspectives, as well as the associated hierarchies
and bureaucracies, and place the emphasis on the processes that are actually performed. Business
processes, as previously discussed, comprise the mechanism for provision of value to the customer,
and BPR is about improving processes to provide more value to the customer.
The philosophy and approach of BPR should not be confused with alternative approaches to organ-
isational change, such as continuous improvement, TQM, rightsizing, restructuring, cultural change and
turnaround. Certainly, a BPR effort may contain elements of these change approaches within its general
philosophy and aims; however, BPR as a concept is far broader than any of these individual concepts.
Principles and approaches
Given the extent of the BPR effort, there are several key steps that should be followed within an organ-
isation to successfully manage the change. Kotter identifies eight steps that should be followed to
manage the transformation of an organisation successfully: establish a sense of urgency, form a leader­
ship team, create a vision, communicate the vision, empower others to meet the vision, plan for and
create short-term wins, consolidate improvements and encourage further change, and institutionalise the
new approaches.51 Each of these steps is further explained in the following sections.
Establish a sense of urgency
The first step in a BPR project is to convince others within the organisation that it is actually required.
While the term ‘establish a sense of urgency’ may seem a little drastic, the challenge is to convince those
who decide whether the project goes ahead that the re-engineering effort is actually required. Since BPR
is such a drastic, organisation-wide approach to redesigning business processes, the people that will
most likely need to be convinced are the top-level managers. Managers who have been within the organ-
isation for a long time may not respond to the call because they do not see the problem or it challenges
their position and sense of security. Therefore, organisational change in the league of BPR often gets
past this first hurdle when a new manager starts work in the organisation, since he or she does not have
the organisational blinkers of a tenured staff member.
Form a leadership team
BPR is not something that can be accomplished overnight. It is a time-consuming and challenging pro-
cess that must involve representatives from across the organisation. It is important, from very early on,
that a leadership team be established to guide the project. This team should be representative of the
entire organisation, and not be made up of representatives from one division within the organisation. The
team might also include some influential external stakeholders, depending on the nature of the changes
to be made.

CHAPTER 2 Business processes 53

 Those on the team should also be of authority sufficient that when they say something needs to be
done it will not be questioned or challenged. A common mistake, according to Kotter, is for companies
to underestimate how difficult it can be to produce change.52 Caron et al. quote a senior manager at a
corporation involved in re-engineering as saying, ‘Everyone knew this was my project. I was the chief
cheerleader, but I also carried a big stick when necessary. I made it clear that this was a project that
required everyone’s commitment and cooperation.’53
Create and communicate a vision
Just as you need a road map to find your way through new cities and towns, so too do organisations
need a map of where they are heading. This business map is described as a vision, outlining where the
business will be after the change takes place, how things will be better, the effect it will have on the
key stakeholders, both internal and external, as well as some outline of how the vision can be achieved.
Communication of the vision throughout the organisation is also a key factor. Akin to giving the Sermon
on the Mount, the preacher of the vision should be able to explain clearly what is happening, why it is
happening and how everyone will be better off as a result. More importantly, it should be in terms that
people can understand. A vision based around the technical jargon of a specific discipline is of little
use because it will prove difficult to communicate to the rest of the organisation. So, as an example, a
change geared around IT should steer away from framing the vision in terms of the technical jargon that
often accompanies the technology discipline. Rather, it should be framed in terms that non-IT people can
relate to, which might include the impact on working roles, work environment and so on.
However, for the people communicating the vision, there can be an added challenge of negative atti-
tudes from the receiver — particularly when visions involving re-engineering are mentioned. In recent
times the term ‘re-engineering’ has become synonymous with corporate downsizing: an excuse to get
rid of some staff. Perhaps one of the causes for this impression was the oft-cited case noted by Hammer
and Champy involving Ford’s re-engineering of its accounts payable department.54 Ford was able to
reduce the staff in its accounts payable from 500 people to about 120 people through a total overhaul
of the process in place. With cases such as this it is little wonder that re-engineering and overhaul
have become interchangeable terms. From an employee’s perspective this can lead to fear and insecurity
about future employment within the organisation. The team entrusted with the task of communicating
the re-engineering vision should be aware of this. Kotter suggests that each negative should be accom-
panied by a positive.55 For example, a company may foresee the elimination of 100 staff members on the
manufacturing floor as a result of re-engineering, but it may also foresee room for growth in the man-
agement of supplier accounts, necessitating new employees in that area. When framed this way, there is
the possibility that the re-engineering may bring about a new job within the firm and not total job loss.
Empower others to meet the vision
Those within the organisation need to be encouraged to try the new way of doing things. Quite often
this can involve more than just employee retraining. While there may be an element of new skills and
training that is required for employees in the re-engineered environment, organisations should also con-
sider other factors that influence employee behaviour in the workplace. For example, the type of bonus
schemes and incentive schemes that are used in the functional environment may not be appropriate in the
process-oriented re-engineered environment.
People do things that get measured, so if performance measures that were appropriate for the old way
of doing things are maintained, then people will still do those things. As an example, looking at the inven-
tory management of a manufacturing company, if the previous performance criterion had been that inventory
stock-outs should be minimised, then the natural response of the manager would be to purchase inventory
and store it on site, thus avoiding the chance of significant disruption caused by stock-outs. If this inven-
tory management process is re-engineered, and as a result adopts a just-in-time inventory management
system, but still pays the manager based on the number of stock-outs that occur, there will be a problem. The
performance system does not match the policy. As long as the manager’s bonus depends on avoiding stock-
outs, that is what he or she will do — through the purchase of inventory and storing it on site. It would be
better to change the performance criterion at the same time to one compatible with just-in-time.

54 PART 2 Systems characteristics and considerations

 The same principle applies to things such as job descriptions and organisational hierarchies. These
should be adjusted so that they can efficiently operate with the re-engineered process.
Plan for and create short-term wins
Any long-term project requires positive feedback for the impetus to remain. Without it, motivation and
drive for the re-engineering effort will wane and people who originally supported the concept may
drop off the idea. To avoid this possibility, landmark events or deliverables should be built into the
re-engineering effort and acknowledged or celebrated when they are achieved. Even though their attain-
ment does not represent the completion of the re-engineering effort, it does signal to employees that the
project is progressing. Psychologically, having to meet short-term deadlines on the way to meeting long-
term goals can also help maintain the urgency and commitment to the project.56
Consolidate improvements and encourage further change
One big risk faced by an organisation is that, once the re-engineering effort is complete, the employees
will adopt the new process for a short time but gradually revert back to the ‘old way of doing things’,
rendering the re-engineering effort unsuccessful. Re-engineering is not only about changing a process
within an organisation; it can also be about changing the culture and attitude that pervade that process.
This is no easy task and can take several years.57
Institutionalise the new approaches
Linked to the previous point, the challenge for the organisation is to make the re-engineered pro-
cess the second nature of employees — that is, change their behaviour so that the new way of
doing things fast becomes the usual way of doing things. This has a lot to do with the culture of
the organisation. The ingraining of the process can be supported through careful selection of staff
when hiring, ensuring that they display a degree of fit with the process in place. This is particu-
larly important because a manager, having completed his or her time with the organisation, could
leave and all his or her work in re-engineering and changing the process could be undone by a new
appointment.
As an example of BPR, consider the following discussion of IBM Credit, based on Hammer and
Champy.58 IBM Credit is a subsidiary of IBM. Its primary operations are to provide credit and
financing arrangements for those purchasing new computers through retail chains, which are sup-
plied with computers and parts by IBM. Its process was originally designed around specialists and
specialist knowledge, with individuals performing specific tasks and forwarding their output on to
the next person in the process. The process began when a store dealer would call the IBM office
with details of an application for finance. This request would be logged by staff at the IBM office
and the details recorded on a document. The document would be sent to the credit department,
where a specialist credit evaluator would enter the details of the application on to the computer and
make a decision on the creditworthiness of the customer. The decision on creditworthiness would be
documented and this document forwarded to the business practices department. The business prac-
tices department staff would draw up loan details, customising the terms and conditions to meet
the requirements of the individual applicant. Any special terms would be added to the application
form and these documents would be sent to a specialist loan pricer, who would determine a suitable
interest rate for the loan. The loan pricer would use a separate computer system, based around a cus-
tomised spreadsheet, to determine an interest rate. The interest rate and other documentation would
then be forwarded to the clerical group. An administrator within the clerical group was responsible
for drawing up the loan document, along with a quote letter. The quote letter would be couriered to
the sales representative who lodged the initial enquiry.
This process is illustrated in figure 2.6. The shaded box represents what happened within IBM
Credit, and the rectangles within the shaded box represent the different divisions or departments
that were involved in the handling of a loan application. The arrows connecting the departments
are labelled with the documentation that the process generated and passed through the different
departments.

CHAPTER 2 Business processes 55

 Call handling Credit Business Loan Clerical
centre department practices pricing group

Sales representative
Sales representative
department division

Log loan Assess credit- Customise Calculate Prepare

Loan request and worthiness loan and interest rate formal Quote
request prepare initial attach special for loan quote letter letter
documentation conditions to
form

• Loan details • Loan details • Loan details • Loan details

document document document document
• Credit • Credit • Credit
assessment assessment assessment
• Special • Special
conditions conditions
• Interest rate

FIGURE 2.6 IBM Credit’s pre-BPR loan application procedure

Having read the description and examined the illustration of the business process in figure 2.6, can you
identify problems with the design of the loan application process at IBM Credit? Consider some of the
discussion presented earlier in the chapter about what a business process is and some of the benefits of
a business process. Did IBM Credit’s procedure before BPR represent more of a business-process-based
perspective or a functional perspective of the organisation?
Arguably, the IBM process represented a very traditional, functional perspective of organisational
design. Notice how the individuals within each department performed a specific function. For example,
the loan pricer’s sole responsibility was to calculate interest rates for loans. He or she had no role in
customising the terms and conditions of the loan or determining the creditworthiness of the applicants.
The demarcation of responsibilities in the different functional areas of IBM Credit was very strong, with
each department having clearly defined duties based around their functional role. This is an attribute of
the functional organisation.
This process design led to some severe problems for IBM, similar to those identified earlier in looking
at the limitations of the functional perspective of the organisation. The primary limitation of this design
was the time that it took to go from the initial request received by the call centre to sending out the actual
loan document to the sales representative. In the process illustrated above, it took anywhere between six
days and two weeks to go from start to finish. That was a long time, especially if you were the customer
waiting for the approval for your purchase to go ahead. This was also undesirable for the sales represen-
tatives, because it risked customers going elsewhere for their purchases because of the lag in the loan
process.
However, an examination of the process revealed that there was not two weeks actual processing time
(elapsed time) involved in handling a loan request. A walkthrough of an application through the system
found that actual processing time was about 90 minutes (time on task). Why then was it taking two weeks
to complete? A disadvantage of the functional perspective is that there can be bottlenecks in a process. A
bottleneck is a backing up or stoppage that delays the normal operation of a process. In the case of IBM,
individuals within the departments would finish their specific task and forward the documents on to the
next division. However, once the documents got to the next stage and division, they would often spend
considerable time waiting in the ‘in tray’ of the person responsible for the task. This occurred because
the design of the process required a lot of hand-offs from one department to another. Sending documents
from one person to another was essential for the operation of the process within IBM, but it did not really
add any value to the loan application procedure and created bottlenecks and delays.

56 PART 2 Systems characteristics and considerations

 What also emerged in the IBM case was the high reliance on specialist knowledge. A specialist is
defined as someone who is recognised as particularly competent in a certain task or procedure. At IBM
specialists were used in assessing the creditworthiness of the customers as well as in determining the
loan interest rates that were to be applied to the approved loan applications. This approach made sense
for abnormal loan applications, but not for all applications. It was therefore possible to re-engineer the
process without relying on the use of specialist knowledge for all loan applications.
Because of these problems, IBM underwent a BPR effort to produce the following process. In the
re-engineered process IBM focused on removing the passing of paper between the different specialists
involved in the original process. The result was that one person handled a loan application from start
to finish and was involved in the entire process. In this way IBM was able to use generalists and move
away from the use of specialist staff. Instead of having specialists to calculate interest rates, customise
loan terms and so on, these tasks were given to all staff involved in the process. Conceptually, this may
sound like a strange solution, because it may appear that these tasks require a degree of knowledge and
expertise to be performed competently. This is indeed true. The approach of IBM was not so much to
make everyone an expert in all stages of the process, but rather to make the knowledge that was required
to complete the process available to all staff. How did the company do this?
IT played a large role in the new loan process, developing computer programs that would support staff
through it. The knowledge of the various specialists was encoded into the program and made accessible
to all staff. As a result, all staff gained the ability to handle a claim from start to finish. How might this
benefit the organisation? For starters, it meant that the large amount of paper shuffling back and forth
between the different specialists involved in the task was eliminated, since one person was able to handle
a loan application from start to finish, and the consequent bottlenecks were removed. Obviously such
a radical organisational change risks delegating tasks to employees who are not sufficiently skilled to
perform them. IBM recognised this by designing a computer application to support the loan process
and keeping a few specialists in each area within the organisation, so that employees handling loan
applications could consult them for advice should any irregular loan applications enter the system. An
examination of the process, however, found that the vast majority of the cases entering the system were
within the realm of a normal application and could be competently handled by a ‘deal structurer’. So
the specialists passed from an integral role in the original process to a support role in the re-engineered
process.
In the end, IBM effectively developed three different processes to handle loan applications. Simple
cases were handled entirely by the computer system, slightly complex cases were handled by the deal
structurer, and the irregular and extremely complex cases were handled by the deal structurer with the
assistance of the specialists in the different areas of the loan application process.
The benefits for IBM were tangible, with a 90 per cent drop in the time it took to process a normal
loan application to about four hours. Additionally, IBM’s loan application handling ability was increased
by a factor of 100.
Some BPR principles in practice
From the foregoing, some principles of a BPR effort become clear. Hammer and Champy59 identify some
aspects to consider. These include combine jobs, have workers make decisions, perform process steps in
a natural order, allow processes to vary, perform tasks at their logical location, reduce the impediment of
controls, reduce the need for reconciliations, and create a single reference point for customers.
Combine jobs and let workers make decisions
In a functional perspective, the precisely defined duties of employees cause bottlenecks and delays in the
process. On top of this, should a person need to consult a superior for a decision, the process can stop
until the decision output from that superior is obtained. One way BPR overcomes this is by changing the
role of the worker. Instead of just performing a particular function, workers have their duties broadened
to include a range of tasks involved in the process. This removes the flow between parties in the process
and can reduce the delays and bottlenecks. Giving the employee the power to make decisions removes

CHAPTER 2 Business processes 57

the emphasis on specialists and specialist knowledge that was present in the traditional structure. In the
IBM case this can be seen in the consolidation of tasks and the use of generalists: now a loan application
is handled by one person, instead of being passed through the organisation.
Create a single reference point for customers
The principle here is that customers should not be passed from one person to another as they search for
answers to questions they have. You have probably experienced this frustrating process when you call an
organisation, are put on hold, are forwarded on to another staff member, who cannot answer your ques-
tion and forwards you on to someone else and so on, and so on. This approach sends the wrong signal
to the customer. It most definitely does not convey the message that the process is geared around serving
its customer. Rather, it suggests that the organisation sees customers’ time as of little value. Giving this
impression to customers is a sure-fire way of losing them!
IBM considered this issue at two different stages of its re-engineering. One idea originally proposed
was to create a central desk that all customers would repeatedly pass through as the different stages of
the application process were completed. The overriding theme was that IBM wanted only one point of
contact for the customer. If a customer had a query, they could call the central desk and get an answer
without being passed around in a game of ‘phone tag’ from one person to the next. The actual imple-
mentation of the single reference point for customers is arguably evident in the creation of the position
of deal structurers, who process applications from start to finish. Customers only need contact their deal
structurer with a query and he or she should be able to answer it, because the continuity in handling the
application allows them to answer any questions that the customer may have about it, such as about the
application’s status in the system.
Perform process steps in a natural order and at their logical location
The idea behind this principle is that if a process consists of several different activities that can be per-
formed simultaneously, then they should be. Traditionally, the functional perspective and its design of a
business process recognised clearly defined tasks that could be performed in a set order. There was little
deviation in the sequencing of activities. In some situations this made little sense because activities could
be done concurrently. The benefit of doing things concurrently is that it can allow for a quicker process
time, benefiting the customer.
In addition to this, work should be performed at its logical location. While this may seem like an
obvious statement, it is not uncommon for work to be passed around from location to location for dif-
ferent tasks to be performed. Elements of this can be seen in the IBM case, with the applications moving
from department to department when, in reality, as is evident in the re-engineered process, all the work
could actually be performed in one place by one person. The benefit of this design is that the process can
be completed quicker with less reliance on specialists.
Allow processes to vary
A process is not necessarily a homogeneous structure that can be applied to all cases. In the IBM case
this can be seen in the role of the specialists in assisting with the more complex loan application cases.
As a result, organisations may need to have slight variations to their process to cater for the different
cases they will encounter. In IBM this occurred at three levels, with a process for simple, slightly com-
plex, and complex loan applications. Most cases fell into the first two categories. Importantly, there was
not one generic process designed to handle the most complex of cases and through which all applications
were sent. This was the mistake in the original design: all cases were treated as though they required the
knowledge of the specialist when, in reality, they did not. There is a need to recognise that variations in
process design might be needed to handle different degrees of complexity once a process is operating.
Reduce the impediment of controls and reconciliations
Traditional process design for the functionally based organisation will typically contain a series of
inbuilt controls. Examples of this can include approval of a superior before an event can occur, reporting
structures, and frequent reconciliations. Quite often these controls and reconciliations add little value to
the process that is being performed. Alternatively, the controls may be important but could potentially

58 PART 2 Systems characteristics and considerations

be improved by combining them with technology. BPR calls for an examination of controls embedded
within a process and a questioning of their value in the process’s operation. An appropriately designed
control framework will embed efficient and effective controls around risky activities in a manner which
does not materially impact processing time. The thoughtful design and development of the control
environment is a major focus in chapters 8–12 of this book.
While the theory of BPR is that a clean-slate approach is necessary, as will be discussed later in this
chapter, this approach is not necessarily optimal. Organisations would seldom start from scratch — the
risks would be immense! However, the principles of BPR can be applied when reviewing and rede-
signing processes, even if not to the extent of the clean-slate approach advocated under a traditional BPR
perspective.

Technology-driven process improvements

One of the principles for business process re-engineering is that technology should be used as an enabler
— the re-engineering process should be geared towards recognition of the ways in which technology
can be applied to improve the operation and functionality of business processes. As is noted by Gregor
et al.,60 ‘Organisations that achieve the most significant benefits from IT exploit these new capabilities
to reform business processes and create new business opportunities’. Businesses will benefit most from
the application of information technology (IT) when the use of IT is driven by the need to solve busi-
ness problems — the use of IT is driven by business needs and opportunities. IT is not incorporated into
a business process just because it is there — there must be an underlying activity or problem that can
benefit from the application of IT. The extent of IT adoption in business processes can start with the
integration of the technology into existing processes, which allows for potentially better process perfor-
mance and ultimately, in the future, the ability to build new capabilities into the process.61 Further down
the line, IT can be used to redesign business processes and alter the way that they are executed.
If we refer back to our process definition, we note that it is customer based. As such, the improve-
ments that are derived from the technology application should also be driven by the needs of the end
customer, since business processes should be customer driven and designed to meet customer needs. But
remember also that the customers of a business process can be both internal and external to a business.
The benefits of re-engineering that can be enjoyed by a customer can include more efficient service
provision, better information availability or a more convenient means of participating in a process. This
is not to say that the business will not benefit from the application of technology within its business
processes as well. Some of the benefits a business can gain from the application of technology within a
process can include a more efficient process, with benefits in quantitative performance indicators such
as turnover rates, as well as more satisfied customers and lower administrative/processing costs. More
generally, a study by Gregor et al.62 lists four main areas in which an organisation can benefit from the
application of technology to its business processes. These areas are summarised below.
1. Information based — refers to the higher level of information that can be made available and the
potentially higher quality of that information.
2. Strategy based — the application of technology that allows a business to create or extend its competi-
tive advantage.
3. Transaction based — the benefit of being able to execute transactions in a more efficient manner and
realise associated cost savings.
4. Change based — the benefits that come from the positive organisational change that can result from
the application of technology within a business process, including new ways of doing business, new
business models, new business plans.
With this in mind, this section provides a brief discussion of some of the different ways in which tech-
nology can be incorporated into a business process. The process examples that are referred to are very
much generic — you will encounter a more detailed discussion of the individual processes in subsequent
chapters. As you read the subsequent process-based chapters you may find it useful to refer back to some

CHAPTER 2 Business processes 59

of the concepts discussed in this section. The intent in this chapter is more to familiarise you with the
ways in which technology can be applied to solve business problems and how it can be incorporated as
part of a redesign of a business process, while also keeping in mind the benefits that can be accrued to
both the customer and the provider of goods and services.
The examples that will be discussed in this section are:
•• vendor-managed inventory
•• evaluated receipts settlement
•• electronic bill payment
•• electronic bill presentment and payment
•• mobile payments
•• RFID or barcoding.
Vendor-managed inventory
Vendor-managed inventory involves the buyer transferring the responsibility for determining what,
when and how much is purchased. The purchasing decision is effectively shifted from the buyer to
the seller. For example, a bicycle company purchases its gear assemblies from Gears Plus. Under a
vendor-managed inventory system, the systems of the bicycle company and Gears Plus would be
integrated, allowing Gears Plus to see how many gear sets the bicycle company has in stock, current
bicycle order levels and expected future bicycle production levels. Based on this data, Gears Plus can
determine how many gear assemblies will be required by the bicycle company. It can then ensure that
this quantity is delivered to the bicycle company in time, minimising disruption and delays in production.
Electronic notification of forthcoming deliveries from Gears Plus will be received by the bicycle com-
pany prior to the arrival of the products, which facilitates a more efficient inventory receipt process.
Visy Industries, a large Australian company that manufactures packaging products, such as boxes and
cans, embarked on such a system with Berri Limited, Unilever and Masterfoods — three of its major
customers. The results included better data sharing, a better supplier–buyer understanding of processes
and more efficient handling of accounts payable.63 These systems can also lead to less duplication in
processes — for example, the buyer entering details for a purchase order and sending that to a vendor
who then re-enters the same data into its sales system. This elimination of duplicated processes has been
found to be a factor in whether or not trading partners engaged in the integration of e-commerce tech-
nology in their respective business processes.64
Evaluated receipts settlement
During the course of business process re-engineering, it is often possible for businesses to completely
overhaul generally accepted procedures; for example, a business might successfully remove the invoice
from its accounts payable process. Such a system is described as an evaluated receipt settlement (ERS)
system. The idea behind the ERS system is that there is little value added by waiting for an invoice to arrive
before paying accounts payable. From an accounting perspective, if we have received the goods, then a
liability is able to be recognised in our accounting system. Waiting for the invoice prior to confirming and
recording the payable merely slows the process and adds delays to our accounts payable turnover.
A critical issue for a business in the purchasing process (which is discussed in more detail in sub-
sequent chapters) is that the goods ordered (as detailed on the purchase order) match the goods received
(detailed on the shipping notice and receiving report) and that the goods received were actually ordered
in the first place (evidenced by the purchase order). If a business is able to confirm that the delivery is for
a valid order and items received match the requested items, then there is little point in delaying recog-
nition and settlement until the invoice is received.
The only requirements for such a system to work are that the transaction must be conducted at
a pre-approved price and transaction costs need to be foreseeable at the time the purchase order is
generated. This approach allows for agreed prices, freight and any taxes or duties to be included in the
purchase order, allowing the purchaser to pay earlier since it is able to accurately determine how much
it owes its supplier.

60 PART 2 Systems characteristics and considerations

 The benefit of an ERS system is that it potentially speeds up the accounts payable process by
the elimination of the invoice from the cash payments process. Such a system allows for expedited
payments to suppliers, which can be beneficial for the supplier’s accounts receivable turnover and
liquidity.
In Australia, as a consequence of the GST legislation and the requirements for tax invoices, the ERS-
based system has led to the introduction of a Recipient Created Tax Invoice. Under a conventional
system where the supplier prepares the invoice and sends it to the customer, this invoice would serve as
a tax invoice for GST purposes. Since the ERS removes the invoice from the system, the preparation of
the invoice for tax purposes is made the responsibility of the purchaser. Legally, this requires a set of
agreements to be in place between the buyer and the supplier and for both parties to be registered with
the Australian Taxation Office with an Australian Business Number.65

Electronic bill payment

Electronic bill payment (EBP) systems allow customers to pay their bills via the internet, mobile or
telephone. This saves customers the time of having to write a cheque or go to a financial institution to
make a payment. Several well-known examples of electronic payment systems are in operation within
Australia, including BPAY and Australia Post’s POSTbillpay (see table 2.2).66

TABLE 2.2 EBP providers in Australia and services provided

EBP provider Web address Services

BPAY View www.bpay.com.au Bill presentation

Bill payment
Bill management

Australia Post www.postbillpay.com.au Bill presentation

Bill payment
Bill management

The advantages of electronic payment systems are that the payment is executed in a more timely
manner and the cost of a transaction is reduced due to the elimination of time and money spent on mat-
ters like clearing cheques. Additionally, removing cheques from the receipts process reduces the risks for
a business or service provider from bounced cheques.
As an example of the use of electronic bill payment technology, the operation of BPAY is dis-
cussed in the following paragraphs. POSTbillpay payments can be made over the counter at post
offices or by telephone or through the internet, and BPAY payments are made over the phone or
through the internet.
EBP example: BPAY
BPAY67 is a technology motivated by a need for a more efficient means of enabling customers to pay
their bills and a business to receive its funds. The initial BPAY system was introduced in Australia in
1997, when nine financial institutions signed up for the technology, and the system was built around
telephone banking. Figure 2.7 depicts the historical growth of BPAY. BPAY provides a means for
customers to pay bills electronically at any time they choose. For a business it has the key advan-
tage of eliminating the timely process of waiting for cheques to arrive from customers, and then
having to go through the process of depositing cheques and waiting for them to clear. The system can
also potentially lead to a reduction in bad debts. These benefits alone can have considerable positive
impacts in the area of liquidity. From a customer’s perspective BPAY offers the convenience of being
able to pay bills in a convenient manner, without having to write a cheque or go into a bank in order
to make a payment.

CHAPTER 2 Business processes 61

 Annual transaction Annual transaction Batch
volume exceeds Payments value exceeds Payments
BPAY $9 million 70% made by $9 BILLION introduced
launches phone

NOV 1997 1998 1999 2000 MAR 2001

BPAY internet BPAY View

payments surpass launches with
phone payments 4 live billers
Annual transaction Master-Sub biller
value exceeds 15 live 10,792 BPAY celebrates arrangement
introduced MB
120 million payments BPAY View BPAY biller 5th birthday
billers codes

2004 2003 NOV 2002 JAN 2002 JUN 2001

2,271,500 bills 10th birthday

The 100,000th celebration &
bill is registered delivered through
BPAY View one billion
DETAILED
$10 billion passes payments made
BILL

Annual transaction through the Scheme 15,820

volume exceeds 26 BPAY View BPAY
$91 billion 350,000 users billers biller codes

NOV 2004 2005 FEB 2006 NOV–DEC 2007 2008

12 Fls offer BPAY BPAY View launched

on mobile banking in first mobile
BILL
DETAILED
banking platform

Over 1 million 2 millionth One million

registrations
DETAILED

20,000 million
BILL

summaries or bills bill registrations

delivered through BPA on BPAY View on BPAY View payments made

MARCH 2011 SEPT 2010 2010 MARCH 2009 2009 MAY 2008

iC QR code Payments
is launRcN launched made by
$20 billion passes hed
through scheme 15,820 BPAY internet
for BPAY payments biller codes 92%

MAY 2011 JUNE 2011 2012 JULY 2012 SEPT 2012

M
OVER
First FI introduces
For small business a BPAY QR code
reader in their
the introduction of BPAY processes an
ED
SAV
customer mobile 54 billers offer average of 1 million mobile banking app MILLION
numbers used for CRN PAY View payments a day

AUGUST 2013 JUNE 2013 MAY 2013 2013 2012

290
Payments News & Insights

OVER
John Banfield BPAY launches BPAY introduces Over 250 billers
appointed newsletter portal ABN as CRN
BILLION now offer
worth of payment
as CEO BPAY Banter for B2B payments through BPAY FY15 BPAY View

NOV 2014 MARCH 2015 APRIL 2015 JUNE 2015 JULY 2015

FIGURE 2.7 Historical growth of BPAY68

62 PART 2 Systems characteristics and considerations

 BPAY is made possible through a unique biller code and reference number that can be found on
the documents of participating institutions. Customers who need to pay a bill simply access their bank
account through either a telephone or an internet banking service. They then enter the biller code and
reference number. The biller code identifies who the payment is going to be received by, while the ref­
erence number identifies the customer and the transaction being paid for. These details are sent through
BPAY to the recipient financial institution, while also letting the recipient know that funds have been
transferred into their account. The customer will receive a transaction number that enables the transac­
tion to be identified and followed up if required.
To explain the operation of BPAY, let us assume that a student has received a re-enrolment notice from
their university advising them that they may pay the annual re-enrolment fee of $250 and that this can be
paid through BPAY. The steps involved would be as follows (follow figure 2.8 for reference).
1. The university sends the invoice for re-enrolment to the customer. This will have information about
how much the student must pay as well as a biller code and a reference number.
2. When the customer receives the bill they can pay using BPAY. In order to do this, they will access
their own banking facilities by phone or through the internet. The internet has become a preferred
option for many. As far back as 2005, 40 per cent of internet users were paying bills online, up from
25 per cent in 2001.69 By 2009, the percentage of BPAY payments made through the internet had
increased to 84 per cent, with 17  000 vendors offering BPAY services. The growth in BPAY vendors
has been around 4.5 per cent per annum.70 The student will enter details that include the account the
funds are coming from, the biller code and reference number from the invoice and the amount to be
paid. The student’s bank account will be updated at this time, with the money being debited.
3. The details of the transaction (the biller code, reference number, amount and a unique transaction
number allocated by BPAY) are then sent through BPAY to the university’s nominated bank. This
does not have to be the same bank as that used by the student.
4. The university’s bank account will then have the amount paid by the student credited to its balance.
5. The details of the transaction will be electronically sent to the university to inform them of the receipt
and provide them with a record of the transaction.

Invoice Student Student’s bank BPAY

1 2 3

University
University
bank
5
University
bank account
4

FIGURE 2.8 The BPAY process

The advantages of the BPAY system for a business process (e.g. billing and accounts receivable, which
is discussed later in the text) are several, including a reduced turnaround time between sending out the
invoice and receiving payment from the customer. This benefit is possible because BPAY eliminates the
need for the billing organisation to process receipts and wait for customer payments (perhaps by cheque)
to be cleared. From an accounting perspective, this can have benefits in areas such as accounts receivable
turnover, cash flow performance and overall liquidity.
Additionally, BPAY can allow the business to focus on its core processes and leave the administration
and processing associated with cash receipts to the BPAY system. For its record keeping, the business

CHAPTER 2 Business processes 63

still receives a summary of all payments received from customers through BPAY. This is made available
in an electronic format that can be uploaded into existing electronic accounts receivable records. Poten-
tially, this facilitates more efficient accounts receivable record keeping.
Electronic bill presentment and payment
Electronic bill presentment and payment (EBPP) is a technology that uses the internet to deliver bills to
customers and then allows customers to electronically make payments on those bills.71 Several examples
of electronic bill presentment and payment systems are in operation within Australia, including BPAY
View and POSTbillpay. As figure 2.7 illustrates, both BPAY and BPAY View have grown considerably
since their inception, with more institutions signed up, a greater number of users and much larger trans-
action volumes than in the initial year of operation.
EBPP example: BPAY View
An example of electronic bill presentment and payment in Australia is BPAY View, which can be seen as an
extension of BPAY. While BPAY and similar EBP developments reduced the time required to process pay-
ments from customers, they still relied on the business sending out a paper invoice to the customer. This use
of conventional mail can be slow and faces a potential risk of the invoice not reaching the customer due to,
for example, the customer changing address or the mail being lost in the postal system. In order to enhance
the benefits of the existing BPAY system, BPAY View was devised, removing the need for a paper invoice.
Using what is referred to as electronic bill presentation and payment, BPAY View operates as follows.
1. The business prepares billing information in an electronic format, usually through a bill service pro-
vider. The service provider then forwards this information to BPAY View, which forwards it on to the
banking institution of the customer concerned. A notification is sent by the customer’s bank to the
customer about the arrival of an electronic bill.
2. The customer then logs on to their internet banking site to view a summary of the bill. They can also
follow direct links to the bill service provider, where more information about the bill can be obtained.
3. The customer is then able to pay the bill. Payment is able to take place when viewing the account or
at a later date.
Advantages of the BPAY View system (and similar EBPP technologies) are that, like BPAY, they offer an
organisation the potential to redesign a billing or cash receipts process. While BPAY and EBP in general pro-
vided benefits in the cash receipts process, as described above, BPAY View and EBPP go one step further and
introduce the application of technology within the billing process. Potentially, this means that organisations
will no longer need to prepare and mail out invoices to their customers alerting them of amounts owing. The
benefits of this for an organisation can be cost savings associated with no longer having to prepare and mail
out the invoices, as well as cash flow benefits, since the invoice reaches the customer sooner, enhancing the
prospect of prompt payment by the customer. Furthermore, in times of increased environmental awareness, it
could be seen as advantageous to eliminate the production of paper-based invoices.
From a customer’s perspective, EBPP offers the advantage of a centralised bill management function
that can be accessed from anywhere in the world. This means customers no longer have to manage a
collection of paper documents, wait for invoices to arrive, or run the risk of losing an invoice. The elec-
tronic delivery of invoices makes them available to the customer anywhere that internet access is avail-
able. EBPP provides a summary of all invoices due for payment and the date when they are due, as an
organisation tool for the customer, reducing the risk of lost invoices going unpaid.
These systems have been expanded to include further bill management facilities as well as EBPP,
with Australia Post offering POSTbillpay. While incorporating EBPP, the management facilities go a
step further and offer the ability for customers to schedule their bill payments, or plan for fixed regular
payments to meet their bills, and thus maintain smooth, regular payments to meet their payables. For the
seller, this can facilitate on-time payments from customers and lower accounts receivable handling costs.
Providers of goods and services need to register with a provider, as they would with EBP or EBPP, for
bill management services to be available to their customers. Once this is complete, their system will be
integrated with the EBPP system in order to facilitate the electronic process.

64 PART 2 Systems characteristics and considerations

Mobile payments
With the advent of mobile technology and the increased number of people with smartphones, the natural
progression is seemingly for banking and payments to be performed using mobile technology. The potential
exists for phones to be equipped with near-field communication (NFC) chips, which would enable the phone
to be swiped against a reader device in order to execute transactions and make payments in a store.72 The
phone is linked, through the NFC chip, to a pre-existing credit facility or bank account offered by conven-
tional banking and finance companies. An argued advantage of this approach to paying for transactions is
that a person invariably has their phone with them when they are out. It also could reduce the need to carry a
wallet full of debit cards, credit cards and cash. Most major Australian banks have made mobile payments a
priority and are rolling out technology that lets customers pay with smartphones.73
Another alternative that has been developed is the ability to use a credit card through a mobile phone,
enabling people to pay bills and transfer funds, typically via small scanners that plug into the phone and
act in the same manner as a credit card reader, with the phone then acting as a credit card processing
terminal.74 The technology also enables touch-based transfers, whereby ‘bumping’ two phones together
can transfer the funds from one account to another. The New York Times describes the following scenario
of two friends who go out for dinner.75
After [dinner] at a San Francisco restaurant recently . . . [Brian Kusler’s] dining companion paid the bill
and asked him for his share. Instead of hunting down an A.T.M., the two bumped their iPhones together,
and Mr. Kusler wirelessly transferred his part of the bill, about $100.
‘I don’t carry a lot of cash; I don’t think anyone does these days,’ Mr. Kusler said. ‘We go out, and I
oftentimes have to remember to pay my friends back when we get home, and I want to be able to just
do it right there.’

This takes the execution of transactions to a new level, with the transactions enabled and executed by
mobile phone technology and the transfer able to take place immediately. The technology is conceptually
similar to smartcard technology that has been employed in various contexts around the world, with a promi-
nent example being the public transport system in the United Kingdom. However, a potential benefit of the
phone-based approach is that there is no need to carry around an extra card. As long as a person has their
phone with them, they are able to carry out a transaction.76 A number of Australian banks have already
released applications that can be downloaded and installed on a smartphone, enabling a customer to log in
and view an account balance, make a payment or transfer funds between accounts. However, despite such
functionality, the applications generally do not facilitate the real-time execution of a transaction in the manner
described above — the customer paying for a purchase on the spot with their phone. This does not mean it will
not happen. Some Australian banks — including Westpac, ANZ, NAB and the Commonwealth Bank — have
experimented with NFC technology. Such trials typically involved bank staff having chips fitted inside their
phone cases, with the chip then being linked to their SIM card. The phones could then be used to pay for trans-
actions, provided that the store was equipped with a contactless card reader (the type used for cards designed
for a tap and pay environment, of which more than 42 000 have been implemented).77 A good example of this
technology is the capability to pay for parking using a mobile phone offered by Brisbane City Council.78
For the banks, this move towards NFC payment methods is seen as an advantage, since it potentially
allows the gathering of more data about customers which ‘can be used to develop better services and to
increase the supply by merchants of popular products’.79 An executive from the Bendigo Bank is quoted
as saying that the use of technology today is ‘about building around the customer and the business, not
the capability of the system’.80 This seemingly emphasises the need to fit the technology to what the
business does and what the customer wants, rather than adopting technology for the sake of it.
However, one current problem with the potential use of NFC payment technology is security, with
limits on the value of transactions that can be automatically executed, restricting access through pass-
words and ensuring that the personal financial data of an individual is not stored on the phone.81
While the technology is still emerging, there are many potential implications and applications of NFC
for business across the areas of information, technology, transaction and change. This could include the

CHAPTER 2 Business processes 65

emergence of cashless processes in which customers execute transactions through their phones, as opposed
to using cash, cheques or credit cards. It is worth noting that the technology preserves the existing link
between customers, financial institutions and retailers; it simply makes the phone the means of payment
instead of cash or credit card.82 For a business process this could have advantages, since cash is highly
liquid and prone to the risk of theft. It could also remove any remaining transactions paid through cheques,
removing the risk of bounced cheques and cheque fraud. Alternatively, the GPS features of smartphones
could enable targeted messages based on the stores the phone user is near, has searched through the
phone’s browser or has purchased from in the past — a new dimension to personalised marketing.83
However, it also poses challenges in the design of the process to ensure that controls are in place to pro-
tect the business and the customer. Such concerns include being able to verify that the phone bearer is the
legitimate account holder and authorised to carry out a transaction. This is similar to concerns about credit
cards and verifying customer identity in an online environment. Additionally, the sending and receiving
of data presents challenges of data protection and security. The security of the phone device could also be
a concern — particularly if banking data is stored on the phone. However, some may argue that phones
are more secure than credit cards due to their ability to be password protected and deactivated remotely.84
From a customer security and financial loss perspective, it was reported that the bank will cover customers
for losses in the event of unauthorised transactions occurring, as long as access details such as PINs and
passwords have been protected.85 Consumer attitudes may also need to be changed — particularly those
who are not early adopters of new technology. The old adage of ‘if it ain’t broke why fix it’ may become
their mantra. An increasing problem is related to the provision of personal data in exchange for free wi fi
access or use of an application ‘If you are not paying for it, you’re not the customer; you’re the product
being sold.86 There is also a possibility of transactions not being able to be carried out due to a phone run-
ning out of battery power — a challenge not present in conventional payment techniques.87
RFID or barcoding
Barcode technology can offer a quick and convenient way to capture data within an accounting infor-
mation system. Barcodes can be incorporated into a business process in a seemingly endless range of
ways. Examples could include the following.
•• Barcode on turnaround documents (e.g. remittance advice slips) to save re-keying as the document
moves through different processes. This can help with the speed at which data is captured, as well as
the accuracy of data entering a system.
•• Barcode inventory. This helps with quick capture of data about inventory receipts and dispatches, as
well as inventory picked, although a direct line of sight is required (i.e. the scanner has to have a clear
line to the barcode in order to read it). For bulky or irregular shaped items this can present a restriction
on the usefulness of barcodes.
•• Barcode for customer and shipping details. These are referred to as serial shipping container codes (SSCCs)
and allow for the tracking of parcels as they move through a logistics process. A barcode is allocated to
each package and it contains details of the supplier and the order details, and links back to data about the
contents of the package. The buyer receives electronic notice of the delivery, which can be incorporated into
the buyer’s system so the barcode is recognisable when the goods are received. This allows the buyer to use
SSCC to identify goods as they arrive in the warehouse. Use of an international standard for barcoding, for
example, the GS1 System standards,88 is important for intercompany operability.
Radio frequency identification tags (RFID tags) are tags that contain a small microchip. As the microchip
comes within range, a transceiver detects a small radio signal from the chip which contains information about
the item or package to which the tag is attached. RFID tags do not require a person to scan the items as they
pass through a reader and do not need a direct line of sight for the tags to be read. Additionally, data can be
stored in the tags and several tags can be read at once by an RFID transceiver.89 This makes capturing data
from tags easier and more efficient than barcode-based systems. The primary difference between a barcode
and an RFID is that an RFID tag can store and share unique individualised data whereas a printed barcode
can only ever be linked to a predefined set of data. An example of the application of RFID technology that
exhibits some of these features and resulted in an improved business process is described in AIS Focus 2.3.

66 PART 2 Systems characteristics and considerations

 AIS FOCUS 2.3

Moraitis lengths ahead

Nick Moraitis is known to many as the main owner of Might and Power, the gelding crowned 1997
Caulfield and Melbourne Cup champion and 1998 Cox Plate king. (The Caulfield Cup, Melbourne Cup
and Cox Plate are three of the largest annual horse races in Australia.) Indeed, while Nick is known as
a successful racehorse owner, he is also a successful businessman, having started up his own fruit and
vegetable delivery business, Moraitis Fresh, in Sydney.
The Moraitis business grew rapidly, and with the growth came the need for better methods of tracking
the produce moving through the company’s distribution system. Moraitis Fresh always prided itself on
being ‘an industry leader boasting a professional operation and state-of-the-art management systems
and technology’.90 As such, the old system of inventory tracking, which relied on markings on boxes,
pieces of paper and standard barcodes to identify boxes, was in need of vast improvement — it was not
as efficient or effective as desired.
In response to this, Moraitis Fresh incorporated RFID technology within its business processes. This
allowed for greater levels of precision when tracking items throughout the business process, with infor-
mation available about the date a package was packed, where it came from, and the contents and
quality of the package. This allowed for better supply chain management and the ability to better mon-
itor the quality of different suppliers.
The initial setup costs were estimated to be around $100  000, but Moraitis Fresh was confident of
quickly recovering that amount.
Moraitis Fresh has also been driven by the needs of the business processes it operates, rather than
just adopting technology for technology’s sake. As the Department of Communications, Information
Technology and the Arts states, ‘As with any technology, its theoretical capability is only half the story.
Its real worth is in how it is put to work. It is the improvements to business processes made possible
by RFID — or the business problems that it solves — that will yield the real value.’91 Moraitis Fresh
evidently thought about how to put RFID to work within its business processes, envisaging that using
RFID would allow it to significantly improve its processes and reinvigorate its supply chain. This should
ultimately deliver a competitive advantage and ensure Moraitis Fresh is just like Nick’s beloved Might
and Power — lengths ahead of the next best in the field.92

Table 2.3 lists the technologies that could be used within a business process to help redesign and
improve business processes. Keep this table in mind as you read through the subsequent chapters which
describe the operation of the different business processes, and consider how these technologies could be
implemented to improve process design for businesses and their customers.

TABLE 2.3 Examples of business processes where technologies could be applied

Technology example Business process where it could be used

Vendor-managed inventory Purchasing process (for buyer)

Evaluated receipts settlement Purchasing and expenditure process (for buyer)

Billing and cash receipts (for seller of goods)

Electronic bill payment Purchasing and payment (for buyer of goods)

Billing and cash receipts (for provider)

Electronic bill presentation and payment Purchasing and payment (for buyer of goods)
Billing and cash receipts (for provider)

Mobile phone payment Billing and cash receipts (for seller of goods)
Purchasing and payment (for retail customer)
Sales and marketing (for bank to understand customer
transactions and needs)

RFID or barcoding Receiving goods (for buyer)

Packing or shipping goods (for seller of goods)

CHAPTER 2 Business processes 67

2.8 BPR evaluated
LEARNING OBJECTIVE 2.8 Critically evaluate BPR techniques.
Hammer and Champy discuss some of the characteristics present in successfully re-engineered business
processes.93 These characteristics (work units change from functional to process, jobs change and people
are empowered), as well as the benefits they present for an organisation, are discussed in the following
paragraphs.
The big benefit for the organisation undergoing BPR, particularly if it is one that was originally
designed around functional principles, is the opportunity to embrace the business process-based design.
Employees within the organisation undergoing BPR can experience a big change in the nature of
the work that they will perform. We saw this in the IBM case, where employees suddenly had a role
in all of the tasks involved in the loan approval process, rather than just one small segment of it.
For an employee this will arguably increase the diversity of the job and make it more interesting. It
also gives employees a greater sense of involvement and control over the process because, in some
cases, the restructuring of responsibilities can lead to decision rights being pushed further down in
the organisation.

Risks and criticisms of BPR

When BPR first emerged as an approach to organisational change there were several high-profile
companies that experienced dramatic benefits from its application, including IBM, Ford and Mutual
Benefit Life. While it worked well for these organisations, a large practical problem ensued. Given
the high profile of the successful companies using BPR, and the nature of the improvements that they
experienced, many organisations reading or hearing about it thought, ‘This is something we can use
as well’, without giving adequate consideration to all that must go into a re-engineering effort. As a
result, many efforts failed or organisations were left disappointed with worse than expected results
from BPR.94
Strassman describes how re-engineering emerged from a heritage of industrial engineering principles,
‘except that it has none of its analytic rigour’.95 Quite often it will involve a management that ‘dic-
tates change primarily from the top of the organization’ and often reflects an approach to organisational
change that considers the reason a particular process design was adopted. Additionally, it should be
remembered that the reality of re-engineering is that it concerns people. Certain ethical and social
issues emerge when we start to glibly refer to people as things that can be moved around, retrained or
‘re-engineered’, much as we would describe a part of a machine.
People are not machine parts that can be ‘re-engineered’.96 Further, given that re-engineering is often
perceived as nothing more than an attempt at ‘downsizing’, employees will be extremely wary when the
word is mentioned. As Strassman states:97
The anxiety of the survivors of reengineering is perhaps the principal reason why companies do not
realize the gains for which they originally planned. Employees who pull through endless waves of cuts
become so distrustful, overworked, insecure and traumatized that their productivity drops and morale is
permanently injured.

One of the major thrusts of BPR is the idea of IT as an enabler of organisational change. This
was evident in the IBM case, with the development of the computer package to handle loan appli-
cations, thus allowing it to create what were effectively case managers while shifting away from the
emphasis on employee specialisation. However, IT is not necessarily the great panacea that Hammer
and Champy make it out to be.98 There is a range of existing research literature that suggests that
investments in IT do not necessarily lead to increases in performance and productivity,99 a phenom-
enon referred to as the productivity paradox. Reasons for this include the reality that investing in a
new IT infrastructure to support a BPR effort will typically bring with it a large range of costs, from

68 PART 2 Systems characteristics and considerations

hardware through to support. Any benefits gained through improved resource efficiency in the pro-
cess perspective could potentially be negated by the increased resources required to support the new
IT within the organisation.
Many organisations are also very wary about the extremity of the clean slate approach that is endorsed
by Hammer and Champy for fear that they will throw the baby out with the bathwater.100 The risks
involved in the clean slate approach are obviously great because with the organisation essentially starting
from scratch, if the newly designed and re-engineered process fails, then there may be nothing left to fall
back on. Davenport provides an example of such concerns at Owens Corning, where, in preference to
a clean slate approach, it adopted a philosophy of ‘“good enough” re-engineering’,101 while Garvin, in
an interview with a CEO of a large American company, found that, ‘process improvement isn’t limited
to large scale reengineering . . . [r]eal power comes from working with small processes — that’s where
the inefficiencies are’.102 As Strassman observes, ‘[r]adical engineering may apply . . . under emergency
conditions of imminent danger as long as someone remembers this may leave an enterprise in a crippled
condition’.103 Davenport and Stoddard observe that although designing from a dirty slate (by consid-
ering existing structures and processes within the organisation) can be ‘a less exciting and more difficult
design method, [it] will normally lead to a more implementable process’.104
In parable-like terms, the fisher who throws back the small fish in the hope of catching the big fish
runs the risk of getting no fish at all, and so going hungry. However, the fisher who keeps the little fish
will eat at night. Many little fish or one big fish — they all taste just as good when they are frying in the
pan. For the organisation, the choice becomes one of waiting for the big fish or being happy to fry lots
of little fish.

2.9 What are Australian organisations doing with

information technology and processes?
LEARNING OBJECTIVE 2.9 Critique the application of information technology (IT) to business processes
by Australian firms.
The preceding discussion of business processes and the use of technology emphasised the way many
people believe organisations should use IT and map their processes. In this section of the chapter we
look at some Australian statistics on technology usage by organisations. These statistics will be linked
back to some of the ideas that we have discussed throughout the chapter as a way of illustrating the
different issues in and concepts of how IT can be incorporated into organisational design and business
processes.

How are businesses using IT?

As discussed previously, the central tenet of business process re-engineering, and indeed any form of
organisational redesign or improvement, is to look for ways technology can potentially be applied to
solve a business problem or create a unique strategic position for an organisation. While the theoretical
perspective presented thus far makes sense on paper, the questions you are hopefully asking are ‘To what
extent does this actually apply in the real world?’ and ‘How are businesses actually using information
technology within their organisational and process design?’
Table 2.4 contains data obtained from the Australian Bureau of Statistics relating to the use of IT
in business in Australia during 2011–12.105 The vast majority (86 per cent) of all businesses use some
form of technology to support their accounting function, while the second most common process to be
enabled by technology is invoicing (77 per cent), followed by human resources (65 per cent). Interest-
ingly, stock control processes reported the lowest use of technologies at 32 per cent; however, it is poss-
ible that the average of this data is skewed by the large number of small businesses in Australia which
quite likely use manual stock control methods.

CHAPTER 2 Business processes 69

 TABLE 2.4 Extent of IT use in business processes

Extent of IT use in business processes, by business process, by extent, 2011–12

Low to Not at all or

moderate extent High extent Any extent Not applicable
% % % %
Accounting 25.7 60.8 86.5 13.6
Production/service operations 23.3 29.5 52.8 47.2
Invoicing 20.4 56.5 76.8 23.2
Stock control 15.1 16.9 32.0 68.0
Marketing 25.1 22.2 47.3 52.7
Human resources including payroll 22.0 42.9 64.9 35.2
Source: Australian Bureau of Statistics.106

Moving on to consider the degree of automation in business systems, table 2.5 looks firstly at the
supply chain, reporting links to suppliers and customers’ business systems. Both large and small firms
report low levels of external linkages (on average 10 per cent), presumably reflecting the level of com-
plexity and expense involved in linking inter-organisational systems. Looking next at business systems
links, the vast majority of organisations (72 per cent) reported no automated systems links; however, there
were differences between large and small organisations. While around 70 per cent of small organisations
(>20 employees) used no automated links, only 44 per cent of large organisations (>200 employees)
had no automation. All businesses were most likely to automate invoicing and payments (15 per cent),
but small businesses were least likely to automate their production or service operations (2 per cent),
whereas the least automated function for large businesses was marketing (11 per cent).

TABLE 2.5 Automated links between systems

Automated links between systems used to receive orders and other business systems, by employment size, 2011–12

0–4 persons 5–19 persons 20–199 persons 200 or more persons Total
% % % % %
Suppliers’ business systems 9.0 11.7 8.4 12.0 10.0
Customers’ business systems 8.5 9.0 12.8 20.3 9.3
Business systems for:
reordering replacement supplies 4.4 5.3 8.1 11.4 5.2
invoicing and payment 13.2 15.4 19.1 27.8 14.8
production or service operations 2.0 4.7 6.7 21.4 3.7
logistics, including electronic delivery 2.9 2.7 6.3 16.1 3.3
marketing operations 7.5 4.3 7.1 11.3 6.3
No automatic system links 73.6 71.4 66.0 44.7 71.8
Source: Australian Bureau of Statistics.107

Moving on from generic use of technology, one of the obvious means for organisations to use tech-
nology is via the internet. As shown in table 2.6, from 2009 to 2012, the number of Australian businesses
with internet access remained relatively static at around 90 per cent, with a 5 per cent increase in busi-
nesses reporting a web presence (40 per cent to 45 per cent). The majority of businesses (99 per cent)
continued to use broadband to connect to the internet. The data show a 3 per cent increase in businesses
receiving orders via the internet (25 per cent to 28 per cent), and an 8 per cent increase in businesses
placing orders via the internet (46 per cent to 55 per cent). Taken together, these data indicate that
internet access has reached saturation point and the number of businesses remains constant; however,

70 PART 2 Systems characteristics and considerations

there is continuing growth in web presence, possibly as business owners have become more familiar
with e-business and have started to move online in greater numbers. This increased understanding or
trust of e-commerce is also reflected in the increasing number of businesses placing orders online, which
is increasing at a greater pace than the volume of online orders received. Most telling of all in the data
is the level of business internet income, which has increased by A$94.3 billion to A$237.1 billion over
a three-year time period. There seems little doubt that businesses that do not have a web presence are
missing out on significant market share and revenue.

TABLE 2.6 Australian business use of the internet

Business use of information technology, selected indicators, 2009–10 to 2011–12

2009–10 2010–11 2011–12

Estimated number of businesses ’000 776 764 776
Businesses with:
internet access % 90.1 91.2 91.9
web presence % 40.0 43.1 44.6
Businesses with internet access and:
broadband as main type of connection % 97.1 99.1 99.2
Businesses that:
placed orders via the internet % 46.5 50.8 55.3
received orders via the internet % 24.8 28.0 27.8
Internet income $b 142.8 188.7 237.1
Source: Australian Bureau of Statistics.108

Looking more closely at web features used by businesses in Australia, the data in table 2.7 indi-
cates that providing information about the business (97 per cent) and providing a facility to contact the
business (91 per cent) are by far the most common web features encountered. Surprisingly, very few
businesses (5 per cent) link their webpage to their back-end systems or use the web to track orders or
personalise customer interactions.

TABLE 2.7 Web features

Selected business web features, by employment size, 2011–12

0–4 persons 5–19 persons 20–199 persons 200 or more persons Total
% % % % %
Information about the business 96.1 98.0 98.8 99.4 97.3
Enquiry or contact facility 90.4 89.8 94.7 96.7 90.8
Online ordering 17.6 19.8 22.7 21.7 19.2
Shopping cart facilities 8.7 8.7 7.6 10.9 8.6
Online payment capabilities 13.5 12.1 14.8 20.4 13.2
Capability for secure access or transactions 10.7 11.7 13.3 24.5 11.6
Client/customer account information 9.8 9.9 12.4 19.3 10.3
Facility to track orders 4.2 4.4 6.1 7.8 4.6
Personalised page for repeat customers 5.4 3.7 4.6 5.5 4.6
Automated link with back-end systems 4.3 4.1 7.1 13.4 4.7

Source: Australian Bureau of Statistics.109

CHAPTER 2 Business processes 71

 In terms of what activities businesses use the internet for, table 2.8 reveals that financial activities are
the most common (84 per cent). The data related to enabling flexibility of employment location are quite
interesting, with small business (<5 employees) far less likely to use the internet to support employees
working from home (38 per cent) or at another location (26.9 per cent), while the respective levels are
much higher for big business (<200 employees) at 77 per cent and 82 per cent. Another magnitude vari-
ation relates to online training, where 30 per cent of small businesses participated in this feature com-
pared to 70 per cent of big businesses.

TABLE 2.8 Business internet activities

Selected business internet activities, by employment size, 2011–12

0–4 persons 5–19 persons 20–199 persons 200 or more persons Total
% % % % %
Financial including online banking, 81.9 88.6 91.1 96.2 84.8
invoicing, making payments
Enabling persons working for this
business to: 38.0 33.6 48.1 76.9 37.7
work from home 26.9 32.0 46.4 82.2 30.4
work from other locations
Information gathering or researching for:
 assessing or modifying this business’ 33.8 45.0 39.5 44.1 37.8
range of products, services, processes
or methods
 development of new or improved 21.4 29.6 30.3 38.6 24.8
products, services, processes or
methods
monitoring competitors 21.2 29.5 33.7 44.1 24.9
identifying future market trends 18.0 21.1 28.2 46.0 20.0
Online training/learning 29.9 36.2 49.5 69.7 33.7
Information sharing or data exchange
(e.g. EDI, FTP) with:
customers or clients 23.4 22.8 26.1 36.2 23.5
 businesses or organisations (which 14.4 16.2 18.9 28.8 15.4
were not customers or clients)
Source: Australian Bureau of Statistics.110

To summarise these data, most Australian businesses use technology to support their accounting, invoicing
and human resources functions. Large businesses have the highest levels of automated system linkages,
mostly used for invoicing and payment making. Nearly all businesses are increasingly using the internet to
place sales orders as well as to receive them. In line with the increase in business-to-business (B2B) trans-
actions, business-to-consumer (B2C) transactions also seem to be increasing, given that internet income has
increased by 60 per cent over the past three years. Despite this potential to increase sales revenues, most busi-
nesses still use the internet as a form of electronic billboard, useful only for providing information about their
business and a contact point for enquiries. The degree of integration with back-end business systems is very
low, as is adoption of the order tracking and personalisation opportunities available. Big businesses are more
likely to be using the internet to create flexible employment opportunities and conduct staff training.

Is IT really improving processes?

The concept of IT as an enabler is fundamental to business process re-engineering as discussed above.
Indeed, whether talking in terms of business process re-engineering or process change in general, there
is little argument against the fact that IT can play a role for an organisation, whether through the use
of the internet or moving towards an enterprise resource planning system. The Australian evidence on

72 PART 2 Systems characteristics and considerations

business use of IT provides some interesting insights into how IT is being applied. This section con-
siders data related to a specific usage of the internet — the business process of receiving a sales order.
Table 2.9 shows that almost a third of all businesses received orders via the internet in 2011–12, with
this practice being more common in large business than small. Table 2.10 reveals that most of these
orders came in via email, and 66 per cent of the time the email was not linked to the website.

TABLE 2.9 Internet commerce, by employment size

Internet commerce, by employment size, 2011–12

0–4 persons 5–19 persons 20–199 persons 200 or more persons Total

Businesses with internet access that:

received orders via the internet % 23.4 34.3 36.8 40.0 27.8
Internet income $b 15.7 ^33.2 ^59.7 128.5 237.1

Source: Australian Bureau of Statistics.111

TABLE 2.10 Methods of receiving orders via the internet

Methods of receiving orders via the internet, by employment size, 2011–12

0–4 persons 5–19 persons 20–199 persons 200 or more persons Total
% % % % %

Email not linked to website 68.6 63.8 59.6 46.6 65.7

Website with linked email facility 31.3 40.9 37.9 23.1 35.5

Website with online order form 13.0 20.3 27.9 35.1 17.4

Website with shopping cart 11.5 11.3 11.1 28.4 11.5

Other methods np np 2.2 4.4 0.5

Source: Australian Bureau of Statistics.112

In simple terms, this would appear to be a positive step, since it removes the need for a paper docu-
ment to be sent by the customer to the organisation. However, the question that we should consider is
how the email facility links to the rest of the organisation. An email facility in isolation would suggest
that orders are sent by email and then printed out or re-entered into the organisation’s other systems
(e.g. the sales system). While this would increase the speed at which the order is received by the organ-
isation, bottlenecks could still exist in the re-entry of the order into other systems. Essentially, a paper
document has been made electronic (the email) but all other processes remain as per the old way of
doing things.113 The other point to notice (see figure 2.10) is that larger organisations tend to be more
sophisticated users of IT when it comes to receiving orders, with 28 per cent of businesses with more
than 200 staff using websites with shopping cart features for taking orders. In contrast, 11 per cent of
small (0–4 people) businesses use shopping carts on their websites, with most small organisations opting
instead for an independent email system for receiving orders.
The issue of integrating processes and data flows across processes, highlighted as missing in the dis-
cussion above about re-entering orders from emails, is brought to the surface in table 2.5, with 72 per
cent of businesses having no integration between their automated order receipt system and other pro-
cesses (note that this is a minor improvement on the 78 per cent reported in 2008). In situations where
systems are integrated, the typical target system is the invoicing and payment system, suggesting sales
data automatically flows through to the invoicing and payment system to facilitate prompt billing of cus-
tomers and the better management of receipts from customers.

CHAPTER 2 Business processes 73

 What the statistics suggest is that, while IT has been recognised by organisations as a resource that can assist in
building their wider presence (e.g. promoting the organisation through the establishment of a website) as well as
improving the operations of the organisation and the workings of business processes, many organisations attribute
the uptake of the technology to several factors, including government support, customer pressure for e-commerce
development and the ability to access technological support for e-commerce adoption.114 Overall, however,
the extent to which technology has been adopted and embraced in line with the tenets of BPR seems to be lim-
ited. The integration of processes, as well as integration with customer and supplier systems, also appears to be
restricted to larger organisations. One could speculate the causes of this discrepancy between the degree of inte-
gration for small and large businesses as including different levels in the need for integration and the availability
of technology and financial resources to support such integration. In its extreme, integration could be attained
through an enterprise system. However, ERP systems have traditionally been seen as costly and prohibitive for
smaller organisations. The data contained in table 2.11 provides some additional evidence on this front, with
almost 8 per cent of small businesses concerned with high IT costs, 8 per cent with a lack of technical expertise
and 2 per cent with online security. The most common reason cited was that businesses believed their goods or
services were unsuitable for selling online (54 per cent) or they preferred to stay with face-to-face customer inter-
actions (41 per cent). It could well be that these beliefs could end up costing these businesses dearly. By opting not
to transact online they are ensuring that none of the rapidly increasing internet income will come their way.

TABLE 2.11 Reasons for not receiving orders via the internet

Reasons for not receiving orders via the internet, by employment size, 2011–12
0–4 persons 5–19 persons 20–199 persons 200 or more persons Total
% % % % %
Goods or services produced by this 51.4 55.7 65.7 66.8 53.8
business unsuitable
Lack of customer demand 12.8 11.4 8.9 8.0 12.1
Security concerns 2.3 2.9 0.9 3.0 2.3
Costs to develop and maintain the 7.1 10.1 6.2 7.2 7.9
technology too high
Lack of technical expertise within this 7.7 10.2 9.0 6.9 8.5
business to develop, maintain and use
the technology
Prefer to maintain current business model 43.2 37.4 31.8 33.7 40.7
(e.g. face to face interaction)
Other 4.2 4.6 3.5 2.5 4.2
Source: Australian Bureau of Statistics.115

Information as a business
Another aspect to consider is the way in which technology is building an entirely new dimension for busi-
ness processes — the information dimension. As mentioned earlier in the package tracking example, the
ability to gather and process data quickly and efficiently using IT has created a means for organisations to add
value in their processes and provide added information for customers. In addition, increasingly technology-­
based processes have created opportunities for third-party organisations to thrive and offer services based
solely on the data available to them. Examples of such a business model include well-known websites such as
wotif.com and lastminute.com.au. These sites provide a resource for those looking to book accommodation,
flights, holiday packages, car hire or activities by offering tools that provide the customer with information
in one place about availability, pricing and value-adds. These sites also offer a booking service for a wide
range of suppliers, such as airlines and hotels. Their core business is built around being able to synthesise and
present informative insights and data in a way that makes booking travel simple, adding value to the customer
experience. This business model is referred to as an aggregator — the business operates by sourcing data
from various sources and compiling or aggregating it in a way that adds value for the end customer.116

74 PART 2 Systems characteristics and considerations

 How do such sites add value to the customer? In the accommodation example, the benefit for the customer
comes from the fact that the customer is able to search and see a range of properties available when the
person wants to travel, and shows comparable pricing in one place, along with additional insights, including
other inclusions (for example, special deals and if breakfast or parking is included), as well as a description
of the property, rooms and facilities (refer to figure 2.9 for an example). This reduces the customer’s search
costs (i.e. the time and effort required to find accommodation). The website’s business relies on the availa-
bility of data from the various hotels (and other travel content suppliers) about what is available, at what price
and when. It earns income through commissions received from hotels as a result of bookings.

Panel A — Wotif home page

Panel B — search results

FIGURE 2.9 Wotif — an accommodation aggregator117

CHAPTER 2 Business processes 75

 This idea can be applied to any information-based process. Technology on Wotif.com and
lastminute.com.au now allows travel and accommodation services to be combined and booked in a
‘package’, which is often a compelling customer proposition based on the savings than can be made as
a result of booking multiple services in the same transaction. Further, after booking a flight, some sites
present accommodation options at the chosen destination. In this manner, organisations are able to link
their business processes and build strategic links with other businesses, for example, airlines with car
hire companies or hotel chains. These links rely on the data about the primary business process (e.g.
airline booking) being available and the technology to share and manipulate the data so it can be used in
a way that adds value for the customer.
An example is Lufthansa. The company made an early move towards understanding its customers
through capturing booking data and other details and using this data to regularly email customers about
travel options, accommodation availability and online booking facilities. This innovation saw Lufthansa
generate more than £17 million in revenue.118 Australian airlines carry out similar procedures through
their frequent flyer programs, which allow them to gather data about passengers and their travel pref-
erences and patterns. In turn, this allows the airlines to send customised emails to customers detailing
the latest flight discounts and destinations. As another example, Marriot had a database of customer
bookings and details that allowed it to ‘create products and services that manifest superior value to the
customer, thus gaining [for Marriot the] ultimate advantage in the marketplace’.119 This would not have
been possible if the data had not been available. As technology continues to proliferate, businesses will
increasingly look to the ability to leverage process data to create avenues for new services, particularly
in service industries where information is the basis of business processes.

SUMMARY
2.1 Identify and interpret the components of organisational strategy and mission.
The process of forming a strategy is based on the overarching mission statement. The mission statement
essentially expresses the organisation’s reason for existence and what it aims to do. The operationalisation
of the mission commences with decisions on strategy, which require the business to distinguish itself from
its competitors and develop a set of activities that best deliver its product or service to its target group.
A business needs to be clear on its strategy and cannot afford to try and be everything to everyone.
2.2 Critique alternative organisational structures, reflecting on their strengths and
weaknesses and the implications for organisational operations.
Two typical organisational structures are the functional and the business process perspectives. In the
functional perspective, a highly structured, rigid organisation is observed that has specifically defined
tasks for employees, with these tasks centred on the various departments of the organisation. In contrast,
the business process perspective recognises the interaction that occurs among departments to accomplish
organisational goals. As a result, the business process-based design for an organisation will produce an
organisation that is leaner, uses its resources better and is more driven by customer needs, since satis-
fying these is the aim of the business process.
2.3 Identify and describe a business process.
A business process is a series of interlocking activities that work together across the organisation to
achieve some predetermined organisational goal. This predetermined goal is typically defined around
satisfying customer needs. A business process is a combination of business functions. Business pro-
cesses can include processes to order raw materials within a manufacturing firm, to manufacture prod-
ucts, to sell products to customers, to handle customer enquiries or to hire new employees.
2.4 Appraise the benefits of organisations adopting a business process perspective.
Resource benefits flow from having a process emphasis. These emerge due to the more highly coord­
inated and integrated approach that the process perspective offers an organisation, reducing wasted

76 PART 2 Systems characteristics and considerations

time due to re-work, bureaucracy and administration. The business process perspective can yield ben-
efits through improved customer service and customer relations, a value-adding emphasis and, poten-
tially, a competitive advantage. Because processes are usually based around the product and therefore
the customer, customer satisfaction, attention and service are potentially higher in a process-focused
organisation.
2.5 Critically evaluate the role enterprise resource planning (ERP) systems play in business
process design.
An ERP system is a complex set of computer program modules that attempts to integrate the different
functional areas of the organisation. Because an ERP system is built around the notion of best prac-
tice, it provides a way for businesses to adopt it. These systems can provide several advantages for the
organisation; however, when adopting them those in charge should be aware of the risks, including the
strategy of the organisation being different from that embodied in the design of the ERP system.
2.6 Intepret and communicate issues for organisations changing to a process-based focus.
Issues that need to be addressed and managed include changes in the role of management and changes
in the design of employee tasks and responsibilities. Changing to a process perspective can mean signifi-
cant changes in the way people perform their duties and as a result decision making occurs further down
an organisation’s hierarchy. Middle managers can see this as a loss of power and offer resistance. In
some cases a layer of managers can become redundant. Workers tend to move from doing one narrowly
defined task to a range of tasks, which can create a more stimulating environment.
2.7 Summarise and evaluate approaches to changing business processes, in particular
business process re-engineering (BPR).
Business processes need to change as the life of the business extends. There are several approaches to
business process change, for example, TQM and BPR. Compared with BPR, TQM is a more conser-
vative approach to change, working from the bottom up and using several small improvements to a
process as the means of improving it, rather than a total overhaul. In contrast, BPR is a radical approach
to change that can sometimes necessitate starting from a clean slate and totally redesigning the way
the process is performed in the organisation. The eight steps to managing BPR are: establish a sense of
urgency, form a leadership team, create a vision, communicate the vision, empower others to meet the
vision, plan for and create short-term wins, consolidate improvements and encourage further change,
and institutionalise the new approaches.
Information technology (IT) can be implemented as part of a BPR strategy. Vendor-managed inven-
tory, evaluated receipts settlement, electronic bill presentation, payment and management, and RFID or
barcode technology can all achieve significant results in a BPR implementation.
2.8 Critically evaluate BPR techniques.
BPR can achieve dramatic improvements by overhauling or replacing an outdated organisational design,
but it carries with it a higher degree of risk than other change approaches and involves more of a top-
down approach. BPR is not without its critics, who often claim it ignores that organisations primarily
consist of people, who are not something that can be re-engineered, as a machine can.
Further, critics often say that to throw out everything and start from scratch is an extreme measure
that introduces unnecessary risk. Many would advocate a much more conservative, small-step approach
to change, rather than the all-encompassing approach that is inherent in BPR.
2.9 Critique the application of information technology (IT) to business processes by
Australian firms.
The data available indicates that the adoption of IT is on the rise, with increased volume of e-commerce
sales and the use of technology to integrate systems within and across organisations. The data also points
to the industry-specific nature of technology application — some industries are well suited to the appli-
cation of technology by virtue of their chosen activities or product and service choices, whereas others
are not as suited.

CHAPTER 2 Business processes 77

KEY TERMS
Best practice The best way of performing a particular process.
Business function A specific subset of the organisation that is designed to perform a particular task
that contributes to the organisation achieving its objectives.
Business process Any set of interlocking activities that work together, across the organisation, to achieve
some predetermined organisational goal, which is typically defined around satisfying customer needs.
Business process redesign The task of changing the operation of a business process in an
organisation.
Business process re-engineering (BPR) The fundamental rethinking and radical redesign of business
processes to achieve dramatic improvements in critical contemporary measures of performance, such
as cost, quality, service and speed.
Functional perspective A view of organisational design that emphasises hierarchical reporting roles,
narrowly specified worker roles and an emphasis on departments.
Information technology (IT) Technology used to handle information and aid communication.
Organisational design (also called organisational structure or hierarchy) The organisation of
a business enterprise through the structure of the relationships, interactions and reporting
responsibilities among staff.
Scientific management An approach to job design that sees workers repeatedly perform narrowly
defined tasks.
Total Quality Management (TQM) An incremental approach to organisational change that works on
the principle that a series of small progressive steps is the best way to improve operations.
Vendor-managed inventory A system that involves the buyer transferring to the seller the
responsibility for determining what, when and how much is purchased.

DISCUSSION QUESTIONS
2.1 Porter suggests that there are two main strategies businesses can adopt. Why is it not possible to
adopt both at the same time? (LO1)
2.2 What is meant by the term ‘operational effectiveness’? (LO1)
2.3 What are the main components of an organisational strategy. (LO1)
2.4 Describe the relationship between the mission statement, strategy and business processes. (LO1)
2.5 Explain what it means for a business if it is considered an aggregator. What is unique about such
a business’s operations? (LO1)
2.6 Explain the difference between a strategy of cost leadership and differentiation. (LO1)
2.7 Describe the differences between the functionally based and process-based organisation. How do
these differences affect how the organisation operates? (LO2)
2.8 What are the organisational advantages and disadvantages of the functionally based and process-
based organisational designs? (LO2)
2.9 What is the relationship between business processes and business strategy? (LO5)
2.10 How can ERP systems enable a process-based organisation? (LO5)
2.11 Describe briefly two of the methods of making changes to a business process, namely
TQM and BPR. (LO7)
2.12 What are some of the advantages and disadvantages of TQM? (LO7)
2.13 Explain what is meant by the term ‘clean slate approach’ in the discussion of BPR. (LO7)
2.14 List and describe, through the use of examples, the principles of BPR. (LO7)
2.15 Identify some of the management issues that may emerge from process redesign.
Discuss their cause, likely consequences and how the organisation may manage these
issues effectively. (LO7, LO8)

78 PART 2 Systems characteristics and considerations

SELF-TEST ACTIVITIES
2.1 The focus of the functional perspective of the organisation is on: (LO2)
(a) controlling the organisation so customers are satisfied.
(b) ensuring the organisation can promptly respond to its operating environment.
(c) controlling staff through specifically defined duties.
(d) integrating the functional areas for efficient operations.
2.2 The benefits of a business process perspective include: (LO4)
(a) a well-defined hierarchy for organisational control.
(b) an integrated horizontal organisation.
(c) delegated power to employees through less reliance on specialists.
(d) specialists doing a large amount of work to ensure its proper completion.
2.3 ERP systems will help an organisation improve its process design when: (LO5)
(a) the existing process is flawed and the strategy of the organisation is consistent with the ERP
approach.
(b) the existing process is flawed and strategies are different to the ERP approach but the
organisation can change to the ERP-defined process.
(c) the existing process is old, having been in place for several years.
(d) the process in the ERP system is different from the existing process used by the
organisation.
2.4 In managing changes in a business process, organisations will often consult lower-level
staff for ideas about improvements. This is done because: (LO6)
(a) lower-level employees need to have the perception they are involved in the change.
(b) lower-level employees perform most of the process and possess valuable knowledge
about its operation.
(c) top-level management fears union reprisals if it does not consult lower-level staff.
(d) lower-level employees can be useful in managing the change process.
2.5 IT as an enabler of BPR means that: (LO9)
(a) all jobs should be performed by computers.
(b) existing processes should be automated using the latest technology.
(c) IT can enable people to better enjoy their work roles.
(d) IT should be used in newly designed processes where possible.
2.6 TQM is designed for (i)______, (ii)______ change, while BPR is more of a (iii)_______,
(iv)_____ approach to change. (LO8)
(a) (i) incremental, (ii) top-down, (iii) moderate risk, (iv) clean slate
(b) (i) incremental, (ii) bottom-up, (iii) radical, (iv) top-down
(c) (i) top-down, (ii) quick, (iii) long-term, (iv) incremental
(d) (i) narrow, (ii) within function, (iii) narrow, (iv) across function

PROBLEMS
2.1 Compare and contrast the functional perspective and the business process perspective of the
organisation. In particular, comment on the different abilities of the structures to (1) minimise
timing delays, (2) respond to change and (3) provide high-quality customer service. (LO1, LO2)
2.2 James McFarlane is the manager of a medium-sized manufacturing company. His company is
looking at improving the design of its purchasing process and one employee has suggested that it
consider adopting an ERP system. The employee said something about the benefit of best practice
in ERP systems. James is not sure which way to go. He believes that the organisation’s current
ordering and inventory management processes are basically sound, unique in the industry and that,

CHAPTER 2 Business processes 79

 with a little modification, they could be even more of a differentiating factor for the business. He
has reservations about ERP systems and was contemplating using a TQM approach to redesign the
process instead of investing in new software.
Advise James on the risks and benefits an organisation faces in adopting the processes in an ERP
system. Should his company go ahead with the ERP system?
Do you think, based on the few facts available, that James should be considering TQM? If so,
which do you think is appropriate for his business? Explain your reasoning. (LO7, LO8, LO9)
2.3 Table 2.12 compares TQM and BPR as ways of improving business processes. (LO7)

TABLE 2.12 Comparing TQM and BPR

Primary criteria TQM (process improvement) BPR (process innovation)
Level of change Incremental Radical
Starting point Existing process Clean slate
Frequency of change One-time/continuous One-time
Time required Short Long
Participation Bottom-up Top-down
Typical scope Narrow, within functions Broad, cross-functional
Risk Moderate High
Primary enabler Statistical control IT
Type of change Cultural Cultural/structural
Source: Williams et al., 2003, p. 2.120

Describe the differences between the two approaches, and explain the potential risks
of each approach.
2.4 Review the before and after re-engineering process descriptions for IBM Credit
in the chapter. (LO3, LO6, LO7)
(a) Explain how this case demonstrates the four elements of re-engineering that were described in
the chapter (fundamental, radical, dramatic, process).
(b) Draw a diagram of the operation of the re-engineered IBM loan application process. Compare
this diagram with that of the original process in figure 2.6. What are the major differences in
the way the process is performed?
(c) One of the solutions for IBM’s process design that was tried was to establish a central desk and
integrate that into the original process. As each person completed their individual task, he or she would
return the loan application to the central desk where it would await collection by the next person in the
process. What do you think would be some of the possible disadvantages of such an approach?
(d) Do you think that there could be any advantages to implementing the central desk approach
described in part (c)? Explain why.
(e) Why do you think IBM did not pursue this option, instead opting for the re-engineered
approach described in the case contained in the chapter?
(f) What could be some of the issues (ethical, technical, legal or otherwise) that IBM would have to address
in implementing the loan application computer support program in the re-engineered organisation?
2.5 Publications by Hammer and Champy121 and Hammer122 advocate a clean slate approach
to BPR. (LO8)
(a) Why do you think they encourage this clean slate approach?
(b) Can you think of any problems that might arise if an organisation simply automates an existing
process, in preference to redesigning it? Explain some of these problems.
(c) Critically evaluate the clean slate approach to BPR. Do you think it is a suitable approach for
all organisations in the midst of process redesign? Why? What could be an alternative to the
clean slate approach?

80 PART 2 Systems characteristics and considerations

 2.6 Describe the operation of an electronic payment system that you are currently using. (LO9)
2.7 Describe and evaluate the disadvantages of electronic payment systems for the:
(a) provider of goods and services.    (b) buyer of goods and services. (LO9)
2.8 Compare the operation of electronic bill payment (EBP) systems and electronic bill presentation
and payment (EBPP) systems. Describe the differences between the two systems. (LO9)
2.9 Assess the relative benefits for a business of adopting EBP and EBPP. Which do you think would
offer the greater benefits when re-engineering a business process? Explain the reasoning behind
your conclusion. (LO9)
2.10 Describe the operation of evaluated receipt payment systems. What advantages would this system
present for vendors of goods and services? How would it improve the operation of a business
process that is undergoing re-engineering? (LO9)
2.11 List some of the potential ways that a grocery retail business could apply the
following technologies within its sales process: (LO7, LO9)
(a) barcode scanning
(b) radio frequency identification (RFID) tags.
2.12 Read AIS Focus 2.3, which describes how Moraitis Fresh employed RFID in its
business processes. Answer the following questions based on the AIS Focus material. (LO2, LO9)
(a) What were the weaknesses of the original processes used by Moraitis Fresh?
(b) Why did Moraitis choose to use RFID tags rather than barcodes when they redesigned their
business process?.
(c) How may the timelines of information available within the business processes at Moraitis
Fresh improve as a result of the re-engineered processes that include RFID?
(d) What factors would Moraitis Fresh have considered when deciding to re-engineer its process
and include RFID tags?
(e) What obstacles might have been faced as part of the re-engineering effort?
2.13 Two EBP providers in Australia include BPAY View and Australia Post. For each provider: (LO4, LO9)
(a) View its website.
(b) List the services offered by each organisation.
(c) Explain who the customers are for each of these organisations.
(d) How might these customers benefit from each of these services offered (bill presentation, bill
payment and bill management)?
2.14 Strides for Strides manufactures and sells athletic wear to retail stores, which sell it on to
customers. Its range of products includes warm-up tracksuits, body suits and running shoes
and spikes. The business process followed by Strides for Strides to supply retail stores
is as follows: (LO3, LO4, LO6, LO9)
•• Retail stores order online using a secure website that sends the order through to their allocated
Strides for Strides customer service representative. Orders are generated periodically by retail
store managers, who typically place an order when their stocks are getting low. Retail stores,
while all being longstanding and regular customers, have typically ordered at the last minute,
resulting in irregular demand levels across the year. The customer service representative checks
that the goods are available and notifies the retail store when their goods will be arriving. Once
the order has been checked, a copy goes to the accounts receivable office.
•• The goods are packed, manually recorded on the goods release form (two copies are prepared)
and sent to the shipping department for dispatch. A courier collects goods and a goods release
form every morning and afternoon and delivers these to the retail store. Once delivery details are
confirmed, an invoice is prepared by accounts payable, based on the details in the customer order
and the goods release form. Electronic invoices are sent out at the end of each week. Retail stores
currently have standard payment terms of 2/15, n/35. Payment can only be made by cheque, which
is sent to the customer service representative who forwards it on to the accounts receivable office.
Strides for Strides has recently noticed that it is having inventory management problems due
to the irregular nature of orders. This has impacted on its own ability to meet customer demands.

CHAPTER 2 Business processes 81

 It is also concerned that incorrect quantities of goods may be packed and shipped, and not
detected until the goods reach the retail stores. This introduces extra costs of handling returns
and allowances. Additionally, Strides for Strides has noticed that its accounts receivable turnover
has dropped from 11.7 times per year to 9.5 times per year over the last 12 months.
An independent consultant has suggested that by re-engineering the process these problems
could be addressed.
Required
(a) For the business process described above, identify:
(i) the participants.    (ii)   the inputs.    (iii)   the outputs.
(b) Identify and describe any inefficiencies that are present in the current system.
(c) Suggest ways that the business process inefficiencies could be corrected through business
process re-engineering.
(d) Prepare a brief narrative that describes how your newly re-engineered system would operate.
(e) Identify and describe the role that technology would play in implementing your proposed
changes.
(f) Describe some of the issues that may be faced by Strides for Strides in re-engineering
processes. Propose some strategies for dealing with these issues.
2.15 Describe the differences between RFID and barcodes as a means of capturing data in a process.
In what situations may barcodes be preferable to RFID? (LO9)
2.16 Damocles’ Kitchenware sells cutlery and dinnerware to customers through a small retail outlet
located in downtown Brisbane. All of Damocles’ sales are to customers who purchase on credit.
Since the existing process for receiving payments from customers is not technology based, all
receipts from customers are either received through the mail or in person from the customer.
Over the past few years, sales for Damocles’ Kitchenware have steadily increased. So too have
accounts receivable levels. A summary of the details is shown below: (LO3, LO9)

Year 2007 2008 2009 2010

Sales for year ending 30 June (all on credit) 125  450 157  993 188  014 212  331

Net profit after tax for year ending 30 June 35  014 44  761 48  536 51  664

Accounts receivable at 30 June 12  500 29  746 55  484 72  467

Concerned about its liquidity, Damocles is investigating the introduction of electronic bill
presentation and payment (EBPP), and EBPP combined with bill management systems
(EBPP/BMS).
Required
Prepare a memo that advises the management of Damocles about the difference in the services
offered through EBPP versus EBPP/BMS. The memo should address the following:
(a) A description of what EBPP and EBPP/BMS are and how they operate.
(b) The advantages of each option for the business and for its customers.
(c) The impacts of the technology on the current operation of the process.
(d) The impact of both systems on process performance and key financial statement ratios.
(e) A conclusion as to which (if any) technology option Damocles should select.
2.17 How does vendor-managed inventory work? What are likely risks of such a system to (a) the
buyer and (b) the seller(LO9)
2.18 Describe how the use of RFID systems could improve the operation of the sales process for a
high-end clothing retailer.(LO5)
2.19 What are some of the potentially negative consequences of outsourcing part of a business
process? (LO8, LO9)

82 PART 2 Systems characteristics and considerations

2.20 Describe the usage of a serial shipping container code (SSCC). How does an SSCC help a
seller and a buyer improve the operation of its business processes? Why is it important to have
standards when using barcodes between different organisations?(LO9)
2.21 List, describe and provide a potential example of each of the major benefits that businesses can
enjoy from applying technology to their business processes.(LO9)
2.22 Refer to figures 2.1 and 2.2. For each mission statement, provide a breakdown of how it
addresses the four components of mission statements mentioned in the chapter.(LO1)
2.23 Use Porter’s five forces model to analyse the Australian airline industry. (LO1, LO2)
(Hint: You may need to consult airline websites and newspapers to complete this.)
(a) How many airlines are there in Australia?
(b) How does each of the five forces apply to airlines?
(c) Do you think all airlines are affected equally by the same forces? Why?
2.24 The strategy discussion in the chapter mentions the need to have activities that are
interconnected and built towards the target goal. Select a business that you know and
describe the following: (LO1)
(a) The target of the business’s strategy (i.e. customers, product, delivery).
(b) The activities the business engages in to deliver its product or service.
(c) The extent to which you think there is a fit between the chosen strategy and the activities in
their sales process.
2.25 Explain, using examples, how businesses can operate on data alone, without providing a physical
product.(LO9)
2.26 Describe the ways in which you think the purchasing processes of a manufacturing organisation
would be different to those of an aggregator. (LO2, LO5)
2.27 Table 2.8 provides data on how businesses use technology to facilitate working from
home and working from other locations. In relation to these ideas: (LO9)
(a) How might employees working from home impact on the design of a business process?
(b) What could be some of the benefits and risks of allowing employees to work from home?
(c) Describe a situation where an employee may be working from locations other than home.
How might technology support such activities?
2.28 The process of ordering food for home delivery has changed with the advent of internet
communication. Here is a description of the process before and after the application of
technology within the takeaway restaurant XYZ Meals. XYZ also offers eat-in facilities but these
are not considered in this case description. (LO9)

Before
Customers ring the restaurant and speak to the maître d’, who asks for the name, address and phone
number of the caller. These details are written on a phone order form.
The second stage is for the maître d’ to record the items that the customer wishes to order. This firstly
involves the maître d’ informing the customer of the daily specials and then listing the items that the
customer wishes to order, along with the items’ quantities and any particular requirements (e.g. how the
meat is to be cooked and any dietary requirements). These details are listed on the phone order form. In
completing the form the maître d’ also refers to the menu and records the price per item and calculates
the line item total (price multiplied by quantity ordered) for each menu item ordered.
The maître d’ then asks the customer for their method of payment. The options are cash on delivery
or credit card (the restaurant accepts all major credit cards). The payment method is then recorded on
the order form. If the customer is paying with a credit card, they then provide the card details — these
include the name of the cardholder, the card type, the card number, the card expiry date and the three-
digit security code. The maître d’ enters these details into the credit card sales processor (an EFTPOS
unit that connects to XYZ’s bank) and the details are electronically sent to the card provider, which
replies with either an accept or decline decision. If the payment is accepted, the customer is then given
an estimated delivery time and the call is concluded.
(continued)

CHAPTER 2 Business processes 83

 (continued)

For credit orders the maître d’ stamps the order ‘Paid by Credit’. If the customer is paying by cash
the order form is stamped ‘Cash to be collected’. Once the payment method is recorded, the maître d’
enters the details from the order form into the computer, which generates a cooking list and two copies
of a sales receipt. The order form and cooking slip are matched and forwarded to the kitchen, where
the meal is cooked.
Once the meal is cooked and packaged for delivery, the driver collects the food items, along with the
order form, cooking slip and two copies of the receipt, and delivers the food to the customer. The customer
receives a copy of the receipt and the food. They are also required to sign the second copy and return it to
the driver, along with the cash payment (for cash sales). The driver returns to the store and gives the signed
documents to the duty manager and then places the cash in the cash register. At the end of the shift, the
manager reconciles the signed receipts, cash takings and credit sales to total sales from the sales register.
After
Food Link decided to place its business on a website called ‘Find Your Food’. Find Your Food is an
aggregator that brings menus from food providers together, making it easier for customers to find a
particular food type when they want it and to compare across different restaurants. The order process
works as follows.
The customer goes to the Find Your Food website and enters their postcode. Based on the postcode
entered, Find Your Food returns a list of restaurants within a 10-kilometre radius, along with the store
opening hours. The customer then selects a restaurant by clicking on its hyperlinked name, and Find
Your Food then provides a list of the menu items available. When a particular food item is clicked, a pic-
ture is displayed along with details of ingredients. This was introduced as a result of concern for people
with allergies to particular ingredients.
The customer then enters the quantities for the food items that they wish to order and the website
calculates the order total. If the order meets the customer’s requirements, the customer is required to
log in using their account name and password (new customers can create an account). Account details
are used for delivery address details and customer contact regarding orders, as well as for marketing by
Find Your Food. The customer details are held by Find Your Food on their computer, which is located in
their Neutral Bay office.
Once the customer is logged in they click on the ‘accept order’ button and enter their payment
details — with customers having to pay by credit card. Once the credit card has been approved the
order is electronically sent to the chosen restaurant.
When an order is received by XYZ meals it is automatically printed out and the maître d’ takes it to the
kitchen for preparation of the meal. When the food is ready the printed order and the food are gathered
by the driver and delivered to the customer. The customer is required to sign the order and return it to
the driver, who checks that the form has been signed and then returns to the store.
At the end of the week the signed order forms are summarised by the manager, who prepares a
summary online order report (a summary report includes the total number of orders, total dollar value of
orders and comments on any ordering issues encountered, e.g. wrong items or disputes over amounts
billed). A copy of the summary report and the signed customer orders are sent to the payment coordi-
nator at Find Your Food. Once the payment coordinator has matched the signed orders with those on
the Find Your Food system, with the matching done using a pre-generated order number that is created
when the customer confirms their order, the funds are transferred to XYZ’s bank account and an elec-
tronic remittance advice is sent to XYZ. Find Your Foods also collects 2 per cent of each sale, as com-
mission, with this taken from the amount to be paid to XYZ.

Based on the cases above:

(a) Describe some of the strengths of the design of the pre-internet process.
(b) Describe some of the weaknesses of the design of the internet-based process.
(c) Identify the main activities that occur in each process. Briefly describe their aim and how
they relate to each other.
(d) Identify the customer(s) of each process.
(e) Explain how the parties you have identified in (d) are customers.

84 PART 2 Systems characteristics and considerations

 (f) Suggest reasons why shifting to Find Your Food may be of benefit to XYZ.
(g) Suggest how the introduction of the internet technology could help XYZ business carry out
its process.
(h) As a customer, suggest some advantages and disadvantages of each process.
(i) Explain why XYZ may be reluctant to integrate its sales through Find Your Food.
(j) Evaluate the extent to which the application of technology seems consistent with XYZ’s
operations.
(k) Identify three measures that XYZ could use to gauge the performance of its processes
(before and after joining Find Your Food). For each measure, explain how it relates to the
performance of the process and what it tells management about process performance.
2.29 Refer to the discussion of the use of mobile phones for payment that is contained in the chapter.
Based on the discussion: (LO1, LO9)
(a) What is NFC technology?
(b) Discuss whether you think the adoption of this technology could provide a sustainable
competitive advantage.
(c) Describe, using examples, ways in which you think this technology could improve the way
business processes operate.
(d) Evaluate the extent to which you think customers would be willing to adopt the technology.
Suggest why some customers may resist the change.
(e) Evaluate the methods of payment for a business process — EFTPOS, credit card and the
proposed NFC mobile phone payment technology — based on their risk to a business and a
consumer. Which would you recommend and why?
(f) Do you agree with the following statement: ‘If all NFC technology does is change payment
from a credit card to a phone-based technique, why bother? Nothing changes!’ Explain your
reasoning.
2.30 Referring to the discussion about the importance of innovation in outsourcing in
AIS Focus 2.2: (LO7)
(a) Why does innovation matter to businesses when they are planning to outsource a business process?
(b) If innovation is unlikely to occur, why would an organisation choose to outsource a business
process?

FURTHER READING
Davenport, TH 1993, Process innovation: reengineering work through information technology,
Harvard Business School Press, Boston
Davenport, TH 1998, ‘Putting the enterprise into the enterprise system’, Harvard Business Review,
July–August, pp. 121–31.
Hammer, M 1990, ‘Reengineering work: don’t automate, obliterate’, Harvard Business Review,
July–August, pp. 104–12.

SELF-TEST ANSWERS
2.1 c, 2.2 c, 2.3 a, 2.4 b, 2.5 d, 2.6 b

ENDNOTES
1. Sidhu, J 2003, ‘Mission statements: is it time to shelve them?’, European Management Journal, vol. 21, no. 4, pp. 439–46.
2. ibid.
3. John Wiley & Sons, Inc. 2012, ‘Mission’, www.wiley.com.
4. Google 2015, ‘Mission’, www.google.com.au.

CHAPTER 2 Business processes 85

 5. Bakos, JY & Treacy, ME 1986, ‘Information technology and corporate strategy: a research perspective’, Management
Information Systems Quarterly, vol. 10, no. 2, pp. 107–19; Simons, R 2000, Performance measurement and control systems for
implementing strategy, Prentice Hall, Upper Saddle River, NJ, pp. 16–37.
6. Porter, M 2008, ‘The five competitive forces that shape strategy’, Harvard Business Review, January, pp. 78–93; Edwards,
C & Peppard, J 1994, Forging a link between business strategy and business reengineering, Cranfield School of Management,
SWP 15/94.
7. Porter, M 1985, Competitive advantage: creating and sustaining superior performance, Free Press, New York, as cited in
Morschett, D, Swoboda, B & Schramm-Klein, H 2006, ‘Competitive strategies in retailing: an investigation of the applicability
of Porter’s framework for food retailers’, Journal of Retailing and Consumer Services, vol. 13, pp. 275–87; Porter, M 1980,
Competitive strategy: techniques for analyzing industries and competitors, Free Press, New York, as cited in Morschett,
Swoboda & Schramm-Klein 2006.
8. Based on Porter 1996, ‘What is strategy?’, Harvard Business Review, November–December, pp. 61–78.
9. Based on Porter 2008.
10. Based on Porter, M 2001, ‘Strategy and the internet’, Harvard Business Review, March, pp. 62–78.
11. Davenport, T 2000, ‘Mission critical: realizing the promise of enterprise systems’, Harvard College, p. 3, www.
harvardbusiness.org/products/9067/9067p4.pdf.
12. Jacenko, A & Gunasekera, D 2005, ‘Australia’s retail food sector: some preliminary observations’, ABARE conference paper
05.11: the Pacific food system outlook 2005–06, Kunming, China, 11–13 May.
13. ALDI Australia 2012, ‘About ALDI Australia’, www.aldi.com.au.
14. Speedy, B 2009 ‘“Frantic” ALDI planners seeing double’, The Australian, 21 January, www.theaustralian.news.com.au.
15. ALDI Australia 2012.
16. Webb, C 2008, ‘ALDI’s simple recipe for success’, The Age, 26 July, www.theage.com.au.
17. Round, DK 2006, ‘The power of two: squaring off with Australia’s large supermarket chains’, The Australian Journal of
Agricultural and Resource Economics, vol. 50, pp. 51–64.
18. Phillips, N 2011, ‘ALDI abandons colour additives’, The Sydney Morning Herald, 22 November, www.smh.com.au; AAP
2011, ‘ALDI removes artificial colours from food’, Herald Sun, 26 April, www.heraldsun.com.au.
19. Burke, K 2009, ‘Supermarket giants checked out, found wanting’, The Sydney Morning Herald, 9 July, www.smh.com.au.
20. Phillips 2011; AAP 2011.
21. Speedy, B 2009; Griffith, GR 2004, ‘Policy forum: competition issues in the Australian grocery industry’, The Australian
Economic Review, vol. 37, no. 3, pp. 329–36.
22. Griffith 2004.
23. Merrilees, B & Miller, D 2001, ‘Innovation and strategy in the Australian supermarket industry’, Journal of Food Products
Marketing, vol. 7, no. 4, pp. 3–18.
24. Webb 2008.
25. Webb 2008.
26. Hintz, P 2009, ‘Now I get it mum’, Paddy Hintz shopsmart blog, The Courier-Mail, 12 June, www.couriermail.com.au.
27. Porter, M 1985, Competitive advantage: creating and sustaining superior performance, Free Press, New York, as cited in
Morschett, D, Swoboda, B & Schramm-Klein, H 2006, ‘Competitive strategies in retailing: an investigation of the applicability
of Porter’s framework for food retailers’, Journal of Retailing and Consumer Services, vol. 13, pp. 275–87; Porter, M 1980,
Competitive strategy: techniques for analyzing industries and competitors, Free Press, New York, as cited in Morschett,
Swoboda & Schramm-Klein 2006.
28. Anthony, RN 1965, Planning and control systems: a framework for analysis, Harvard University Graduate School of Business
Administration, Boston.
29. Based on Sandoe, K, Corbitt, G & Boykin, R 2001, Enterprise integration, John Wiley & Sons, Inc., New York, figure 2.2,
p. 18; figure 2.4, p. 20; figure 2.10, p. 31.
30. Powell, L 2002, ‘Shedding a tier: flattening organizational structures and employee empowerment’, The International Journal
of Educational Management, vol. 16, no. 1, pp. 54–9; Stoner, JAF, Yetton, PW, Craig, JF & Johnston, KD 1994, Management,
2nd edn, Prentice Hall, Sydney.
31. Powell 2002, p. 58.
32. Byrne, JA 1993, ‘The horizontal corporation’, Business Week, vol. 20, December, p. 44.
33. Based on Sandoe, Corbitt & Boykin 2001, table 4.1, p. 55.
34. ibid.
35. Cusumano, MA 1988, ‘Manufacturing innovation: lessons from the Japanese auto industry’, Sloan Management Review,
vol. 30, Fall, pp. 29–39.
36. Sussan, AP & Johnson, WC 2003, ‘Strategic capabilities of business process: looking for competitive advantage’, Competitive
Review, vol. 13, no. 2, pp. 46–52.
37. Friedman, TL 2006, The world is flat: a brief history of the twenty-first century, Penguin Group Australia, Camberwell.
38. Lacity, MC & Willcocks, LP 2013, ‘Outsourcing business processes for innovation’, MIT Sloan Management Review, vol. 54,
no. 3, pp. 63–69.
39. Friedman 2006, pp. 24–28.

86 PART 2 Systems characteristics and considerations

40. Switzer, R 2006, ‘Outsourcing opens doors in global village’, The Age, 19 March, www.theage.com.au.
41. Lacity & Willcocks 2013.
42. Davenport, TH 1998, ‘Putting the enterprise into the enterprise system’, Harvard Business Review, July–August, pp. 121–31.
43. Volkoff, O 2003, ‘Configuring an ERP system: introducing best practices or hampering flexibility?’, Journal of Information
Systems Education, vol. 14, no. 3, pp. 319–24.
44. Porter 1996.
45. Hammer, MJ & Stanton, S 1999, ‘How process enterprises really work’, Harvard Business Review, September–October,
p. 109.
46. Hammer & Stanton 1999, pp. 109–10.
47. Smith, M 2003, ‘Business process design: correlates of success and failure’, The Quality Management Journal, vol. 10, no. 2,
pp. 38–49.
48. Hackman, JR & Wageman, R 1995, ‘Total Quality Management: empirical, conceptual and practical issues’, Administrative
Science Quarterly, vol. 40, 1995, pp. 309–42.
49. Cusumano 1988.
50. Hammer, M & Champy, J 1994, Reengineering the corporation: a manifesto for business revolution, Allen & Unwin, Sydney,
p. 32.
51. Kotter, JP 1995, ‘Why transformation efforts fail’, Harvard Business Review, March–April, pp. 59–67.
52. Kotter 1995.
53. Caron, JR, Jarvenpaa, SL & Stoddard, DB 1994, ‘Business reengineering at CIGNA Corporation: experiences and lessons
learned from the first five years’, MIS Quarterly, September, p. 237.
54. Hammer & Champy 1994.
55. Kotter 1995.
56. Kotter 1995, p. 66.
57. Kotter 1995, p. 66.
58. Hammer & Champy 1994.
59. Hammer & Champy 1994, pp. 50–64.
60. Gregor, S et al. 2004, Achieving value from ICT: key management strategies, Department of Communications, Information
Technology and the Arts, ICT Research Study, Canberra, p. 12.
61. Gregor et al. 2004, pp. 81–84.
62. Gregor et al. 2004, p. 11.
63. National Office for the Information Economy 2006a, ‘Advancing with e-business: supply chain case studies: Visy Industries’,
www.dcita.gov.au; National Office for the Information Economy 2006b, ‘Advancing with e-business: supply chain case
studies: Berri Limited’, www.dcita.gov.au.
64. Department of Communications, Information Technology and the Arts 2006a, Engaging trading partners in e-business,
Commonwealth of Australia, Canberra, p. 29.
65. Australian Taxation Office 2006, ‘Grants and GST: recipient created tax invoices’, www.ato.gov.au.
66. Reserve Bank of Australia 2006, ‘Payment systems developments and architecture: some background’, p. 4, www.rba.gov.au.
67. BPAY and BPAY View are registered trademarks of BPAY Pty Ltd. POSTBillPay and Billmanager are registered trademarks of
the Australian Postal Corporation. Use here is purely for educational and demonstrative purposes.
68. BPAY 2009, ‘BPAY today’, www.bpay.com.au.
69. Centre for International Economics and Edgar, Dunn & Company 2006, Exploration of future electronic payments markets,
Australian Government Department of Communications, Information Technology and the Arts (DCITA), Canberra, p. 49.
70. BPAY 2009, ‘BPAY today’, www.bpay.com.au.
71. Reserve Bank of Australia 2006.
72. ‘Money? There’s an app for that’, The Economist, 26 May, www.economist.com.
73. Bender, A 2014, ‘Updated: mobile payments in Australia: state of the banks — Commbank, Westpac, CUA and
Bendigo enable smartphone transactions’, Computerworld, 29 January, www.computerworld.com.au/article/536949/
mobile_payments_australia_state_banks/.
74. Miller, CC & Bilton, N 2010, ‘Cellphone payments offer alternative to cash’, New York Times, 28 April, www.nytimes.com.
75. Miller & Bilton 2010
76. Neate, R 2011, ‘Mobile phone firms team up to develop “wave and pay” system’, The Guardian, 16 June, www.guardian.
co.uk.
77. Tay, L 2011, ‘Commbank launches contactless payment app’, CRN, 26 October, www.crn.com.au; Tay, L 2011, ‘Westpac trials
Near Field payments’, CRN, 13 May, www.crn.com.au.
78. Brisbane City Council 2014, ‘Parking meter mobile phone payments’, www.brisbane.qld.gov.au/traffic-transport/parking-
permits/parking-meters-fees/parking-meter-mobile-phone-payments.
79. Boyd T 2011, ‘Death of the credit card’, Australian Financial Review, 26 October, p. 64.
80. Pennington, S 2011, ‘Game-changing technology the key to business survival’, The Age, 16 November, www.theage.com.au.
81. Koremans, S 2011, ‘Commonwealth Bank kick starts end of the credit card with new payment app’, News.com, 22 November,
www.news.com.au.

CHAPTER 2 Business processes 87

 82. Boyd 2011.
83. Pennington 2011.
84. ‘Mobile payments key to future’, Australian Financial Review, 15 August 2011, www.afr.com.
85. Boyd 2011.
86. ‘Userdriven discontent’, MetaFilter, community weblog, 26/8/2010, www.metafilter.com/95152/.
87. ‘Mobile payments key to future’, Australian Financial Review, 15 August 2011, www.afr.com.
88. GS1 2007, ‘GS1 BarCodes: implementation’, www.gs1.org.
89. Department of Communications, Information Technology and the Arts 2006b, ‘Getting the most out of RFID’, Department of
Communications, Information Technology and the Arts, Commonwealth of Australia, www.dcita.gov.au, pp. 1–5.
90. Moraitis Wholesale 2006, www.moraitis.com.au.
91. Department of Communications, Information Technology and the Arts 2006b, p. 2.
92. IBM Corporation 2005, ‘Moraitis Fresh can deliver improved customer relationships with an IBM RFID solution’,
On Demand Business, IBM Corporation, New York, www-935.ibm.com.
93. Hammer & Champy 1994, pp. 65–82.
94. Davenport, TH & Stoddard, DB 1994, ‘Reengineering: business change of mythic proportions?’, MIS Quarterly, June,
pp. 121–27.
95. Strassman, PA 1995, The politics of information management: policy guidelines, The Information Economics Press, New
Canaan, Connecticut, p. 226.
96. Strassman 1995, p. 226.
97. Strassman 1995, p. 234.
98. Hammer & Champy 1994.
99. Davenport, TH 1993, Process innovation: reengineering work through information technology, Harvard Business School
Press, Boston.
100. Hammer & Champy 1994.
101. Davenport, TH 1999, ‘Enterprise systems and process change: still no quick fix’, Financial Times, London, 22 February, p. 6.
102. Garvin, DA 1995, ‘Leveraging processes for strategic advantage’, Harvard Business Review, September–October, p. 82.
103. Strassman 1995, p. 230.
104. Davenport & Stoddard 1994, p. 123.
105. This is the most recent data available from the Australian Bureau of Statistics at the time of publication.
106. Australian Bureau of Statistics 2013, ‘Extent of IT use in business processes’, Business use of information technology
2011–2012’, cat. no. 8129.0, www.abs.gov.au.
107. Australian Bureau of Statistics 2013, ‘Business systems supporting the receipt of orders’, Business use of information
technology 2011–2012, cat. no. 8129.0, www.abs.gov.au.
108. Australian Bureau of Statistics 2013, ‘Business use of information technology, selected indicators, 2009–10 to 2011–12’,
Business use of information technology, 2011–12, cat. no. 8129.0, www.abs.gov.au.
109. Australian Bureau of Statistics 2013, ‘Selected business web features, by employment size, 2011–12’, Business use of
information technology, 2011–12, cat. no. 8129.0, www.abs.gov.au.
110. Australian Bureau of Statistics 2013, ‘Selected business internet activities, by employment size, 2011–12’, Business use of
information technology, 2011–12, cat. no. 8129.0, www.abs.gov.au.
111. Australian Bureau of Statistics 2013, ‘Internet commerce, by employment size, 2011–12’, Business use of information
technology, 2011–12, cat. no. 8129.0, www.abs.gov.au.
112. Australian Bureau of Statistics 2013, ‘Methods of receiving orders via the internet, by employment size, 2011–12’, Business
use of information technology, 2011–12, cat. no. 8129.0, www.abs.gov.au.
113. Kandampully, J 2002, ‘Innovation as the core competency of a service organisation: the role of technology, knowledge and
networks’, European Journal of Innovation Management, vol. 5, no. 1, pp. 18–26.
114. Scupola, A 2009, ‘SME’s e-commerce adoption: perspectives from Denmark and Australia’, Journal of Enterprise
Information Management, vol. 22, no. 1/2, pp. 152–66.
115. Australian Bureau of Statistics 2013, ‘Reasons for not receiving orders via the internet, by employment size, 2011–12’,
Business use of information technology, 2011–12, cat. no. 8129.0, www.abs.gov.au.
116. Madnick, S & Siegel, M 2001, ‘Seizing the opportunity: exploiting web aggregation’, Paper 144, December, Centre for
ebusiness at MIT, www.digitalmit.edu.
117. www.wotif.com.
118. Willocks, LP & Plant, R 2001, ‘Pathways to e-business leadership: getting from bricks to clicks’, MIT Sloan Management
Review, Spring, pp. 50–9.
119. Kandampully, J 2002.
120. Williams, A, et al. 2003, ‘Total quality management versus business process re-engineering: a question of degree’,
Proceedings of the Institution of Mechanical Engineers, vol. 217, no. 1, p. 2.
121. Hammer & Champy 1994.
122. Hammer M 1990, ‘Reengineering work: don’t automate, obliterate’, Harvard Business Review, July–August, pp. 104–12.

88 PART 2 Systems characteristics and considerations

ACKNOWLEDGEMENTS
Figures 2.1, 2.4: © John Wiley & Sons, Inc.
Figure 2.2: © Google.
Figure 2.3 and table 2.1: Sandoe, K, Corbitt, G & Boykin, R 2001, Enterprise integration, © John
Wiley & Sons, Inc., New York.
AIS Focus 2.2: © 2013 from MIT Sloan Management review / Massachusetts Institute of Technology.
Figure 2.7: © The BPay Group.
Tables 2.4 to 2.11: © Australian Bureau of Statistics 2015.
Figure 2.9: © Wotif.com.
IBM Credit discussion: © Nicholas Brearley Publishing, Case study ‘IBM Credit’ from ‘Reengineering
the corporation: a manifesto for business revolution’, Michael Hammer & James Champy, Nicholas
Brealey Publishing, London, 2001, pp. 39–42.
Table 2.10: © Sage Publications UK, From ‘Total quality management versus business process
re-engineering: a question of degree’, Williams, A, et al., Proceedings of the Institution of
Mechanical Engineers, 2003, vol. 217, no. 1, p. 2.
Photo: © AlexRaths / iStockphoto.

CHAPTER 2 Business processes 89

CHAPTER 3

Database concepts I
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

3.1 explain the role of databases in decision making and reporting systems
3.2 define the function of a database and the concept of database systems
3.3 demonstrate the concept of data redundancy and the advantages of databases
3.4 discuss database systems and justify the use of the relational database
3.5 apply database modelling and exercise judgement to develop database models using
entity–relationship diagrams
3.6 critically describe how relationships in a database model reflect how an organisation works.
Introduction
In any organisation, accurate, relevant and timely information is crucial for good decision making and
reporting. In modern organisations, databases are the foundation of high-quality data capture, storage and
management for decision making and reporting. This chapter first discusses basic database concepts. Next,
it examines poor data system characteristics to provide an insight into the main anomalies that can occur in
poorly designed systems and the benefits that databases can provide if properly designed. This discussion
provides a useful perspective for accountants, as well as database users, designers, developers and imple-
menters. The chapter then looks at the operation of database systems, including the role of database manage-
ment systems (DBMS). Examples of how to develop relational databases based on business relationships are
examined in some detail. This is because relational databases are the most common in business organisations.
To maximise the benefits offered by relational databases, careful database modelling, data relationship
design and systems implementation are crucial. The final section of the chapter looks at how to construct
database models of an organisation and its interactions with suppliers and customers. These constructs
are called entity–relationship diagrams (shortened to ER diagrams). ER diagrams consist of entities (the
‘E’ in ER diagrams). Entities are anything about which an organisation may want to store information.
Examples of entities for T Construction Industries (described in AIS Focus 3.1) include inventory sup-
plies, suppliers, customers and houses. The ‘R’ in ER diagrams stands for relationships. This looks at
the relationships between entities, for example, the relationship between customers and houses or the
relationship between inventory and suppliers. As the name suggests, ER diagrams model the entities an
organisation wants to record information about and the relationships between those entities. Once the
entities and relationships in an organisation have been modelled (the conceptual model), the ER diagram
can be used as a basis for implementing a physical database in a database product such as Microsoft
Access (through converting the conceptual model into the implementation model). ER diagrams can also
be used in the opposite way: they can help users, designers and developers of databases to understand
the relationships that already exist in an operating organisation’s database. Good design of databases is
essential for the efficient, fast, error- and duplication-free flow of information in a database system. A dis-
cussion of top-down modelling (ER diagrams) and bottom-up modelling (normalisation) concludes the
chapter. In chapter 4, the normalisation process for efficient database design from the bottom up is exam-
ined. This process overcomes the problems of repeating groups, data anomalies and data redundancies.

CHAPTER 3 Database concepts I 91

 AIS FOCUS 3.1

T Construction Industries
Damien is the financial accountant for T Construction Industries. He wants to purchase a new accounting
system database for his organisation. In doing this, he wants to know if all databases are the same; that
is, how he can evaluate a database to find out how suitable it is to how his organisation operates. He is
concerned that if he buys a certain database package he may need to change how his organisation works
to fit with the new system. Damien needs to know the specific decision-making aspects he wants included
in the system and to evaluate potential systems against these aspects. He also needs to ensure that the
system stores data in the most efficient and effective manner. Katrin, a friend of Damien’s, has suggested
that she design a database system to fit his organisation. Damien likes this idea as a potential alternative
to buying an existing database system. Katrin has suggested that Damien, as an accountant, needs to
understand database concepts to ensure that the database he chooses or has designed will fit his organ-
isation. This will also allow him to make informed user contributions to the design of the system and com-
municate with systems analysts and programmers, an equally important requirement for small databases
an organisation constructs and large-scale information system implementations.

3.1 The role of databases in decision making

and reporting systems
LEARNING OBJECTIVE 3.1 Explain the role of databases in decision making and reporting systems.
One of the advantages of a database is that all the data for the whole of the organisation is contained
within the database system. For example, in the absence of a database, an employee in one department
such as sales wanting to check on inventory levels would have to contact the inventory department and
enquire about inventory balances. This is because each department in an organisation would have its own
information system. A database system enables all the data of the organisation to be contained within
the one system. In a database system, data such as inventory levels can be updated in the system by the
inventory department and made accessible to staff members across all departments in the organisation
that need the information. The same information may be needed for a variety of purposes. For instance,
an employee in sales may want to know how much inventory is available for immediate delivery to cus-
tomers, while an employee in accounts receivable may want to know how much inventory customers
have purchased on credit. Using the database system, both employees could access the information for
their own purposes.
Managers require accurate, relevant and timely information to make strategic and operational
decisions for their organisations. Examples of such decisions would be whether to continue manufac-
turing and selling an existing product (generally a strategic decision), to invest in new plant and equip-
ment (generally a strategic decision) or to stop production and service machinery because reports show
an increasing number of defects from production (generally an operating decision). Decisions involve
formulating different scenarios and making a choice between the alternatives. A database system allows
managers to access and evaluate the data they require to make such decisions. For example, given the
database contains all sales orders, a manager could access the sales orders for the day and match them to
the goods that have been delivered during that day. At the end of the day, they could see the number of
orders that were made during the day and not dispatched. This information could be kept in the database
system, and if the percentage of undelivered orders rose above that of the previous week, the dispatch
or general manager could be advised that there may be an issue with deliveries. The manager could
then investigate the number of orders outstanding and make a decision about what action to take, for
example, increase the level of inventory for a particular item of stock if a majority of the orders relate to
that item. This decision-making example illustrates the importance of timely and accurate information,
in this case, so that decisions can be made on whether or not there is an issue with dispatching goods.

92 PART 2 Systems characteristics and considerations

 Information is derived from facts or data that are processed in a meaningful form. The form of the
information must suit the objective of the information. For example, an item of data could be the expen-
diture of each customer in the current month. To determine the total sales for the month, you would sum
the sales amount for each customer. But this is not the only question you might ask of the data. What if
you want to know how much each customer spent in the month? Or which customers spent more than
a particular amount? Or who were the first-time customers for a promotion? These questions can be
answered if the data are captured and stored at their most basic level, and then aggregated at a level that
will answer each question.
To ensure meaningful information can be derived, it is important to capture, store and manage data
as efficiently and effectively as possible. Data is not information; rather, data is stored in databases
and information is derived from this data by retrieving it in a meaningful manner. Storing data is best
achieved in a database. A database (or database system) is a computerised software program that enables
data in an organisation to be captured and stored. A relational database stores data in tables, which form
the entities in an ER diagram. A DBMS within a database contains programs that enable adding data to
entities, manipulating existing data and producing reports.
It is important that database entities and relationships be designed to eliminate repetition and incon-
sistent data. Such a well-designed data structure allows for efficient and effective data sharing across an
organisation. In addition, with all data in a central place, data privacy, security and backup are essential
to ensure data are protected.
After studying this chapter, you should fully understand the advantages of databases. For now, some
key points that underpin the importance of database concepts in information systems used by modern
organisations can be stated.
•• Correct decision making and reporting are vital for organisational performance.
•• Correct decision making and reporting require accurate, relevant and timely information.
•• Accurate, relevant and timely information comes from quality data capture, storage and management.
•• Data are the building blocks of information.
The next section will begin to discuss the concepts of databases and, in particular, the relational data-
base, as this is the database model most widely used in business.

Design of database models in relational databases

Database models are a collection of logical constructs used to represent the data structure and the data
relationships found within the database. In figure 3.1 four models are depicted: external models, con-
ceptual models, implementation models and physical models. The external model is the model that
relates to the end-users’ views of data. The end-users are from different groups in the organisation such
as marketing, accounting, accounts payable or accounts receivable. Each of these external users needs
to use different aspects of the database to perform their decision making and reporting. All the different
aspects they require in a database would be combined to form the conceptual model.
The conceptual model uses an entity-relationship diagram to show the relationships in the system.
Conceptual models focus on a logical view of what is represented in the database. The conceptual
model covered in this chapter is the entity–relationship model, which is explained for database model-
ling and design through the ER diagram in section 3.5. The conceptual model’s logical representation,
or view, shows what is represented in the database independent of hardware and software (also covered
in section 3.5). The conceptual model contains the entities and the relationships between them. The
relationships are shown as being one-to-one, one-to-many and many-to-many. Many-to-many relation-
ships cannot be implemented in an actual computerised system. Therefore, there is a process through
which conceptual models are converted into implementation models. These implementation models are
what can be installed on a computerised database program. Conceptual models cannot be installed on a
computerised database package as all the aspects needed, such as keys and many-to-many relationships,
are not resolved. However, they are a first step in modelling an organisation’s data requirements.

CHAPTER 3 Database concepts I 93

 The implementation models in figure 3.1 show how data are represented in a database product such
as Microsoft Access, including the structures implemented. Implementation models are covered in detail
in section 3.5.

External users External users External users External users

External model External model External model External model

Conceptual model
Entity–relationship diagram
(ER diagram)

Implementation model
Entity–relationship diagram (ER diagram)
normalised

Physical model

FIGURE 3.1 Types of database models for relational databases

This text discusses predominantly the logical view of conceptual models. The physical model includes
some of the physical aspects required to implement a system. The physical representation of the client–
server model, which shows all the specifications of hardware and software, is not considered until the
final section in the next chapter on database implementation.
Therefore, there is a process in designing a database, from the external model to the conceptual model
to the implementation model, which will be discussed in section 3.6. Before we look at this process, we
need to cover some database concepts.

3.2 Database concepts

LEARNING OBJECTIVE 3.2 Define the function of a database and the concept of database systems.
There are various types of database. The most commonly used in business is the relational database. As a
result, this discussion of database concepts concentrates on the relational database. This type of database
is based on the entities in the database and the relationships between them. Relational databases typically
store data in a number of tables. The way the relational database system stores things is very similar to how
the ER diagram depicts them. So, it is very easy to go from an ER diagram (a diagram with entities and

94 PART 2 Systems characteristics and considerations

relationships), a conceptual model, to a relational database (an implemented implementation model). The
relational database uses entities, which it calls tables, and shows the relationships between the tables.
Therefore, a relational database is a collection of carefully defined tables. A table is a collection of
columns or attributes that describe an entity (or something you wish to record data about in a database).
A record consists of a set of fields, which characterises a person, place or thing within the business or
linked to the business. Fields describe a particular characteristic of each record, such as name, address
or phone number. Fields are derived from data or facts.
Consider the example of a retail store that sells shoes. The store keeps a customer file containing a
record for each customer. Each customer record contains fields that include customer number, customer
name, customer phone number and customer address. Each of the fields contains data. The computerised
customer table shown in figure 3.2 is recorded in much the same way as a record would be made in an
old-fashioned paper-based filing system. As in a paper-based filing system, each customer has his or her
own file and every time he or she buys shoes from the retail store, the store updates the information in
the file with a new record.
As shown in figure 3.2, a table can also be called an entity or an entity occurrence. A field can also
be referred to as a column or attribute. Individual objects are stored as records within the table. A record
can also be called a tuple or row. These words are used interchangeably to describe databases, so famili-
arity with all the terms is important.
Before computers, many organisations kept separate files for each administrative function, such as
sales orders or entry processing, accounts receivable, inventory and invoicing. For example, when a
sales order or entry was taken, organisations would process the order by updating three files: a sales file,
inventory file and customer file. In addition, in accounts receivable, staff would update a similar sales
file, inventory file and customer file. Staff in the warehouse would also update their inventory file and
customer file. In other words, the one transaction required changes to two sales files, three inventory files
and three customer files! Databases enable all departments to access a single view of the sales, inventory
and customer data.

Field, column, attribute

Customer_number Customer_name Customer_address Customer_phone

1 Swati Takutai 6 Glenelg Street, 03  1234  5678

Record, tuple, row
Melbourne, VIC

2 George Broomfields 36 Bourke Street, 03  9876  4321

Melbourne, VIC

3 Britney Micawber 12 Jones Street, 03  5678  3456

Melbourne, VIC

4 Michelle Burford 4 Lonsdale Street, 03  2376  1048

Melbourne, VIC

Table, entity, entity occurrence

FIGURE 3.2 Example of a file — ‘Customer file’

The table in figure 3.2 could represent the entity ‘customer’ for an organisation. This is because there
is a customer number (Customer_number) that represents a customer name (Customer_name), which is
one instance of a customer that is stored in the customer table. A number is used to represent a customer

CHAPTER 3 Database concepts I 95

as customer names are not unique. You might think your name, for example, John White, is unique. But
my university had six John Whites attending all at the same time. Five were students and one was a
teaching staff member. If we only used ‘John White’ to identify the record (row/tuple) when we wanted
to retrieve the data about the student John White we would retrieve one of the records but lose five.
Therefore, it is important to have a unique identifier for each instance in a table, such as each student
in a student table. Since names are not unique, we generally assign a number (e.g. a student number or
customer number). Assigning a name a unique number is important — just think of all the numbers you
have: student numbers, customer numbers, library numbers and so on.
Every table in a relational database must have a primary key, which is an attribute (or column)
that uniquely identifies a particular object (or row) in the table. Suppose figure 3.3 is a project table
with project number (Proj_num), project name (Proj_name), project start (Proj_start) and project budget
(Proj_budget) as attributes. Either Proj_num or Proj_name could be used to find a particular project
entry, but Proj_num is a better primary key because it is likely to be unique, whereas a project name can
be duplicated. The uniqueness of the number relies on the organisation assigning a unique number to
each project — it could do the same with the name, but it would become difficult over time to come up
with different names. Also you would need to spell them consistently correctly or it would perceive it as
a different project. Pukenamu below, for example, could be difficult for individuals to consistently spell
correctly. A combination of unique alpha-numeric codes may be suitable. Therefore, the most important
issue with a primary key is that it is unique and can never point to more than one object (or row) in the
table. The primary key is also indicated by a bold underline, as shown for project number (Proj_num)
in figure 3.3.

Proj_num Proj_name Proj_start Proj_budget

1 Oceania 01/01/2015 $10  000

2 Parade 01/04/2015 $30  000

3 Pukenamu 01/12/2014 $50  000

FIGURE 3.3 Project table

The table in figure 3.4 shows the example of a number of employees assigned to work on projects.
In this case, the table will use more than one column as part of the primary key. Such a primary key is
called a composite key.

Proj_num Proj_name Emp_num Emp_name Time_charged

1 Oceania 101 Michael Burford 12

1 Oceania 105 Brett Micawber 2

1 Oceania 110 Phil Musick 3

2 Parade 101 Michael Burford 4

2 Parade 108 David Smith 5

3 Pukenamu 110 Phil Musick 6

3 Pukenamu 105 Brett Micawber 5

3 Pukenamu 123 Michael Clovely 5

3 Pukenamu 112 Josephine Wyatt 8

FIGURE 3.4 Project employee table showing data redundancy and anomalies

96 PART 2 Systems characteristics and considerations

 Take a look at figures 3.3 and 3.4. These two tables are common in consultancy businesses which have
projects and employees who charge time to the different projects that they work on. We have a table in
figure 3.3 that contains project details that relate the project name to its unique project number. The pri-
mary key is the project number. The table in figure 3.4 is the project employee table, which shows the
projects and which employees are engaged on each project. This table has two attributes that make up
the primary key — Proj_num and Emp_num, because the table is designed to show which employees are
engaged on a project and how much time they charge to that project. Each employee (Emp_num) can be
engaged on many projects (Proj_num). For instance, Emp_num 101 appears against project numbers 1
and 2. Because each employee can be engaged on many projects, Proj_num must be part of the primary
key. Similarly, each project can engage many employees (e.g. Proj_num 1 has three employees). Since
each project can engage many employees, Emp_num must be part of the primary key. The combination
of Proj_num and Emp_num as a primary key is known as a composite key. This is because we need both
attributes, Proj_num and Emp_num, to define each line uniquely. A composite key can also be called a
concatenated key as the composite key is comprised of two or more attributes together (the word concat-
enate means to put together).
Some examples will illustrate the application of the primary key. Note that in the Proj_num, Emp_
num example, although two attributes are used to determine the primary key, the primary key is still a
singular. That is, there is one primary key made up of two attributes. A primary key (a singular) can be
made up of more than two attributes. Three or four attributes could be used to determine a primary key.
The number of attributes used is the minimum number of attributes required to uniquely identify each
line in the table. For example, in the above case you would not use the project name as it is not needed;
project number and employee number are the minimum sufficient number of attributes required for the
primary key to uniquely identify one line in the table.
To show that you need both attributes, Proj_num and Emp_num, to define one line uniquely, consider
Proj_num = 1, Emp_num = 105. This will return the row shown in figure 3.5 from figure 3.4.

Proj_num Proj_name Emp_num Emp_name Time_charged

1 Oceania 105 Brett Micawber 2

FIGURE 3.5 Selected rows in project employee table, Proj_num = 1, Emp_num = 105

Another example would be Proj_num = 3, Emp_num = 105, which returns the row from figure 3.4
shown in figure 3.6.

Proj_num Proj_name Emp_num Emp_name Time_charged

3 Pukenamu 105 Brett Micawber 5

FIGURE 3.6 Selected rows in project employee table, Proj_num = 3, Emp_num = 105

A secondary key is also possible. A secondary key allows the user to search on an attribute other than
the attribute(s) that form the primary key. In relational databases, it is possible to search and query on all
attributes (i.e. they all function as secondary keys). Therefore, it is not necessary to indicate a secondary
key in a relational database.
An important aspect of a relational database is that the tables must be carefully defined to provide
flexibility with minimum issues. The issues that may result from an inflexible file structure will be illus-
trated in the next section on data redundancy.

CHAPTER 3 Database concepts I 97

 3.3 Data redundancy
LEARNING OBJECTIVE 3.3 Demonstrate the concept of data redundancy and the advantages of databases.
Well-designed databases contain all the information an organisation needs in one place. Because data
is updated immediately, any information extracted from the database is accurate and up to date. This is
important for the managers of an organisation in making decisions.
Data redundancy occurs when the same data is stored in multiple locations in an organisation. For
example, an accounts receivable department has a customer table with each customer’s primary key, and
their address and phone number. The marketing department has a customer table containing the cus-
tomers they send brochures to. This table also has the customer’s primary key, and their name, address
and phone number. This is an example of data redundancy, as the same data is stored twice for one cus-
tomer in a database. If a customer’s details change, there is a risk that the changes will be made in only
one place, which will result in inconsistent as well as repeated data in the organisation.
Good database design can eliminate problems of repetition, inconsistent data and data errors because data
in databases are recorded in files that are shared across functions and departments, rather than having the same
data stored in different places and by different functions across the business (as occurred before the advent of
databases). Early information systems, sometimes referred to as functional or silo systems, serviced indepen-
dent departments. In contrast, more modern cross-functional systems share data in order to leverage a com-
petitive advantage. However, if data are to be stored only once and in only one place, the data structure needs
to be flexible. For example, assume the customer file in figure 3.7 is stored in a database. This table includes
the customer details and inventory sold to them. This means that if Michael Burford’s address changes it
needs to change in two places: line 2 and line 5. If there were thousands of purchases by Michael Burford, the
address would need to be updated correctly on every line. If not, it would cause an update inconsistency.
In summary, only one correct record of the customer details is required in the organisation. Having the
details occur in more than one place produces data redundancy. The first implication of data redundancy is
data inconsistency, where there are different and conflicting versions of the same data in different places.
For instance, if a customer’s address is changed in most of the lines but not all, the sales reports will yield
inconsistent and incorrect results. In this way, the inconsistent data lead to a lack of data integrity.

Customer_ name Customer_ address Customer_ phone Salesperson Bicycle_ model Bicycle_ amount Date
1 Britney Micawber 55 Hattaway Street, 03  1234  5678 TLM VZ4717 $1229.90 20-Jul-15
Melbourne, VIC
2 Michael Burford 4 Compass Street, 03  9876  4321 CBD DF3966 $2379.50 30-Jul-15
Melbourne, VIC
3 Phillipa Musick 8 Cook Street, 03  5678  3456 MTL WE9447 $1050.30 4-Aug-15
Melbourne, VIC
4 Devine Smith 3 Mellons Street, 03  2376  1048 JFK XC8187 $845.50 6-Oct-15
Melbourne, VIC
5 Michael Burford 4 Compass Street, 03  9876  4321 CBD BF7266 $1790.50 30-Sep-15
Melbourne, VIC
6 Britney Micawber 55 Hattaway Street, 03  1234  5678 TLM XV2397 $825.90 20-Aug-15
Melbourne, VIC

FIGURE 3.7 A customer file showing the importance of flexible data structure

The second implication of data redundancy is that it can lead to a number of data anomalies. These
anomalies occur because changes need to be made in several places rather than in just one. More
specifically, these anomalies can be classified into different types: modification, insertion and deletion.
Figure 3.7 of the customer file of a bicycle retailer has already shown how a modification anomaly can
occur in relation to the updating of Michael Burford’s address in multiple rows of the table.

98 PART 2 Systems characteristics and considerations

Modification anomalies
Modification anomalies can occur when a field value is changed. For example, the new address for a cus-
tomer (such as Michael Burford above) requires changes to be made to all the customer file records that
relate to Michael Burford in the system. Depending on the size of the file system, this could number hun-
dreds or even thousands of records. Inconsistencies and a breakdown in integrity are likely. For example,
the allocation of a new salesperson to specific customers that is not correctly updated in all files would
result in a different salesperson recorded for the same customer in different places in the organisation.

Insertion anomalies
Insertion anomalies can occur when new customers are entered into the customer file. Businesses can
often acquire many new customers in a single day. If this occurs, customers must be matched with a
particular salesperson and their details. Such a situation may occur in a construction business such as
T Construction Industries, described in AIS Focus 3.1. Customers that begin with certain letters of the
alphabet may be assigned a certain salesperson. As the details of the salespeople must be entered as
many times as there are new customers, errors are likely to occur. Similarly, if the organisation employs
a new salesperson, their details would have to be filed together with the customers they will look after.
Look again at the project employee table in figure 3.4. This table is a good example of an insertion
anomaly. As we discussed earlier, the project employee table has a composite primary key: the primary
key is composed of two attributes, Proj_num and Emp_num. We wouldn’t be able to add a new pro-
ject with no employee assigned to it. This is because both attributes that constitute the primary key are
required. Therefore, we couldn’t insert a project until an employee is assigned. Or we couldn’t enter an
employee until they are assigned to a project. Entering a fictitious employee number against a project
number would not be appropriate as it is an internal control issue.

Deletion anomalies
Deletion anomalies can occur when a salesperson decides to resign from the organisation or the organisation
terminates the employee’s employment. As illustrated in figure 3.7, when this occurs, customer records have
to be modified to reflect the lack of a salesperson or modified with the details of a newly assigned sales-
person. Another example is shown in figure 3.4: if we decide to delete project 3 we would lose all the infor-
mation about Josephine Wyatt (employee number 112), as this is the only project she is assigned to.
As a result, when we design database systems, we need to ensure their structure is flexible and won’t result
in modification, insertion and deletion anomalies. The technique called normalisation, covered in chapter 4,
is a process we can perform to ensure we do not encounter anomalies in our database structures.

3.4 Database systems and functions

LEARNING OBJECTIVE 3.4 Discuss database models and justify the use of the relational database.
This part of the chapter explains database systems and database management system (DBMS) functions.
Currently, most businesses use relational databases, so this chapter concentrates on this model. Older
database models, including hierarchical and network models, are not discussed. These older database
models were built around separate files, while modern information systems collect, store and retrieve
data from a database shared with other departments. Object-oriented databases are discussed briefly.

Database systems
A database system (another term for a database) is a collection of elements that allow the capture,
storage, management and use of data within a database environment. These elements include hardware,
software, people, procedures and data.
Hardware refers to the system’s physical devices, which include the computer and computer periph-
erals. The computer may be a microcomputer, minicomputer or mainframe computer. It may even be part

CHAPTER 3 Database concepts I 99

of a client–server system. Peripherals include items such as keyboards, mice and printers. The software
is the collection of programs used by the computers to function and includes operating system software,
database management system (DBMS) software, application programs and utilities. Operating system
software makes it possible to run all other software on the computer. Microsoft Windows is an example
of operating system software. The DBMS software allows the database within the database system to be
managed. The DBMS is, in effect, an operating system exclusively for the database. Some examples of
DBMS software include Microsoft Access and SQL Server. Application programs and utility software
are used to access and manipulate the data for generating reports and any other information for decision
making. Utilities also help to manage the different components of the database system.
There are likely to be several people involved in a database system. System administrators manage
and supervise the database system’s general operations. There are also database administrators, who
manage the use of the database and ensure that all the functions are working properly. Since a database
serves cross-functional information systems and also exists independently of the separate information
systems, it requires a technical specialist such as database administrators to monitor performance, deal
with changes to the structure and carry out backup procedures. Ensuring that data has privacy controls,
security and backup are extremely important tasks of a database administrator. They also give access to
staff to different areas of the database, depending on the level of access approved for each staff member.
Database designers develop structures and designs that capture data for storage and manipulation. As
shown by the discussion on data redundancy above, data structures and designs play a critical role in
overcoming some of the limitations that can be inherent in some systems. Systems analysts and pro-
grammers create the screens, reports and procedures by which end-users can access and manipulate the
data in a database system.
Procedures are the rules that govern the design and use of the database system for the organisation. They
often reflect the processes by which a business deals with its customers, updates its records and reports to its
shareholders. They ensure that the data and information maintain quality and are meaningful and consistent.
The determination of which data are entered into the database and how they are organised is the role
of the people within the database system, especially the database designer. The database designer often
analyses the decision-making and reporting requirements of the business before defining what data is
required and how it should be defined and captured in the database. Figure 3.8 shows the elements of the
database system: the DBMS, data, application programs, hardware, people (in particular, the database
administrator, database designers, analyst and programmers) and procedures.
Database designers
Analysts
Procedure and
End-users Programmers
business rules

Systems administration
Database administration

Application
DBMS
programs

Data

FIGURE 3.8 The database system

100 PART 2 Systems characteristics and considerations

 The strength of the relational approach is that the designer does not need to know which questions
may be asked of the data. If the data are specified and defined carefully, the database can answer virtu-
ally any question efficiently. The efficiency and flexibility of a relational database is the main reason for
its dominance today.
These strengths come from the structural independence of the data. That is, it is possible to
make changes to the database structure without affecting the ability of the DBMS to access data.
This is because every table is independent and because relationships can be constructed just by
linking key fields in tables. There are other strengths of a relational database. Conceptually, users
can easily comprehend the logical view of the database as the tables of data are easy to understand.
The structural independence of the data makes it easier to design, implement, manage and use. There
are also some very powerful and flexible query languages that users can easily learn (as they do
not require programming skills) which can be used to manipulate the data for answering their own
questions. For most relational databases, the query language is SQL. The SQL engine does all the
tough jobs in the database, such as creating table structures and maintaining the data dictionary,
system catalogue and table access, and translating user requests into a format that the computer can
handle.
However, the conceptual simplicity of the relational database makes it easy for poor design and imple-
mentation to creep in. Users can find it easy to generate reports and queries without much thought about
database design.
It is also easy for organisations to have databases within databases because users may start creating
their own databases and applications for their specific use. As the database grows, a lack of proper
design slows the system down and produces the types of repetition, data anomalies and data redun­
dancies found in other database systems. That is why well-designed database systems are essential, as is
knowledge of the basics of database design for a business accountant.
Most small business systems software, such as MYOB and QuickBooks, uses relational database
structures. To maximise the advantages offered by the relational database system, careful database mod-
elling, data relationship design and systems implementation are critical. These factors are explained in
section 3.5.

Advantages of database systems

Database systems are designed to eliminate the repetition of data and the incidence of incon-
sistent data by ensuring data is structured so that it is stored in only one location. This structure
allows for data sharing across the organisation and provides the foundation on which any data-
base can be developed. The incidence of errors is reduced considerably by independent data struc-
tures, with only one location for entering and manipulating data. Program maintenance is also
reduced because there is only one centrally located point, the DBMS, that requires reprogramming
for all data (this will be covered in the next section). This increases the speed and flexibility with
which the organisation can prepare information that is crucial to decision making. The centralisation
of data in the DBMS enforces consistent standards for data structures and storage across the organ-
isation. It also aids data and system security by having only one access point into the database to
control. Given this, and as indicated above, privacy, security and adequate backups to the system are
important.
To maximise the advantages offered by the database system, careful database modelling, data relation-
ship design and systems implementation are essential. Details on these issues are provided in section 3.5,
which deals with the principles behind each of the database system aspects of development, design and
implementation.

DBMS functions
Figure 3.9 shows the data flow for a typical database system.

CHAPTER 3 Database concepts I 101

 Inventory

Accounts Reports
payable
Data
Suppliers
definitions

Inventory Reports
Purchase control
order
DBMS

Warehouse Order
Reports
entry

Sales
Invoicing Reports

Customer

FIGURE 3.9 The DBMS function in a typical database system

Data are stored in a central location, such as a specific database storage device in the IT department of
an organisation, and managed by a DBMS. Data definitions are required in the DBMS before program-
ming, and the DBMS is used to define and specify the business rules and corresponding data require-
ments and calculations for the organisation’s business processes. Reports as required by the organisation
can be produced from these business processes.
The DBMS contains a number of useful functions. They include:
•• a data dictionary
•• data storage management
•• data transformation and presentation
•• security management
•• multiuser access control
•• backup and recovery management
•• data integrity management
•• access language and application programming interfaces
•• communication interfaces.
The data dictionary contains a definition of the data elements and their relationships with one
another, such as the relationship between a supplier number and an inventory number, or between
a customer number and an invoice number. For example, the definition of ‘purchase date’ and the
way it is to be coded (e.g. ‘Purchase_date’) are used consistently for that attribute throughout the
database. Also, if the attribute is a date, the day, month and year order will be provided to show how
it should be formatted throughout the database (e.g. ‘dd/mm/yy’). Data storage management helps
to manage the capture of input, and the application of business rules, codes and structures to those
inputs, so that the inputs can be transformed and stored in the database structure. Behind data storage

102 PART 2 Systems characteristics and considerations

management lies entry forms, screen definitions, data validation rules, procedural code and struc-
tures to handle video, pictures and the like. Data transformation and presentation allows the entered
data to conform to the existing data structure. It translates requests into commands that store, locate
and retrieve the requested data. The security management of the database enforces user security and
data privacy within the database by scrutinising access and data operations, while multiuser access
controls provide data integrity and consistency to many users simultaneously without compromising
the integrity of the database. The DBMS also provides for backup and recovery management, which
contains procedures that perform routine and special backup and restorations in the event of data-
base failure caused by, for example, bad sectors on a disk or power failure. Access language and
application programming interfaces allow the database to be queried using an appropriate query lan-
guage such as structured query language (SQL), while communication interfaces such as Internet
Explorer allow the database to accept end-user requests within the computer network environment.
SQL, for example, is a language that allows the user to specify what must be done without having
to specify how it is to be done. Many of the tasks of a DBMS are administered by a database
administrator whose job it is to control access by users to the database, maintain the data dictionary
and oversee backup and recovery in the DBMS. The database administrator is very important from
the internal control perspective as they plan, design and give access to the database and ensure the
ongoing operation and maintenance of the database. For example, if a request for a report is made,
the database administrator must ensure that the user requesting that data view should have access to
the information in the tables they have requested.

Other database systems

Object-relational and object-oriented databases
Object-relational databases and object-oriented databases are other database models, which, as the
names suggest, are object relational and object oriented. Object-relational databases have the advan-
tage of being able to use the relational tools of structured query language (SQL) and tables to be
able to interrogate the database. Object-oriented databases are based on the concept of objects,
which, in turn, are based on object-oriented programming principles. Object-oriented databases are
a good model if the database is required to store a lot of sounds, pictures or video (e.g. films, or
medical or scientific images). The concepts of classes, inheritance, extensibility and encapsulation
from object-oriented programming are applied to object-relational and object-oriented databases.
Data is stored as objects; an example of an object would be a customer. A customer object would
store data and programs that would act on that data in the same object. Many customer objects
would be stored as a class of objects. Classes of objects such as customers can be stored in a hier-
archy. Customer objects at the bottom of a hierarchy (such as a retail customer) can inherit data
attributes such as customer payment terms from above them in the hierarchy (such as a wholesale
customer). Objects are encapsulated, meaning that objects cannot see all the data and programs of
other objects.
Object-oriented databases also have the advantage of data types. Accounting systems have, for
example, dollars, dates and whole numbers as data types. In object-oriented databases, new data
types can be created; however, given dollars terms are generally used in accounting systems, we
generally do not need this ability to create new data types, which is called extensibility. An item of
data stored as an object in an object-oriented or object-relational database has data and methods that
can be performed on the data. So, the data and the programs that operate on the data are not separate
as they are in a relational database. This fact introduces more complexity into the database design
process.
For financial accounting systems that focus on monetary values, usually a relational database is suf-
ficient, and this is why we study the relational database in this text.

CHAPTER 3 Database concepts I 103

3.5 Database modelling, design and
implementation of relational databases
LEARNING OBJECTIVE 3.5 Apply database modelling and exercise judgement to develop database
models using entity–relationship diagrams.
Database modelling and design are the first two steps in describing complex real-world activities in
such a way that they can be captured by and represented in a database system. Database modelling and
design, as discussed in this section, utilise a conceptual view with logical representations of database
structures.
There are two steps to this process: the design of the conceptual model and the design of the imple-
mentation model.
As discussed in section 3.1 and shown in figure 3.10, database models are a collection of logical
constructs used to represent the data structure and the data relationships found within the database.
These database models can be grouped into two categories: conceptual models and implementation
models. Conceptual models focus on a logical view of what is represented in the database. The con-
ceptual model covered in this chapter is the entity–relationship model, which is explained for data-
base modelling and design in section 3.6 through the ER diagram. The conceptual model’s logical
representation, or view, shows what is represented in the database independent of hardware and soft-
ware. Implementation models show how data are represented in a database product such as Microsoft
Access, including the structures implemented. Implementation models are not covered in detail in
this text.

External users External users External users External users

External model External model External model External model

Conceptual model
Entity–relationship diagram

Implementation model
Entity–relationship diagram normalised

FIGURE 3.10 Database models

104 PART 2 Systems characteristics and considerations

Database modelling
Database models are used to describe and represent complex real-world data structures. These con-
ceptual models provide a logical representation, in graphical form, of the complexities of real-world data
entities and their relationships with one another. At the same time, a database designer can depict the
data structures, relations, characteristics and constraints on their design using a database model. Conse-
quently, it is a communication tool that can provide the blueprint for developing new database structures
or create improved understanding of an organisation’s database.
There are important reasons for database modelling. First, a good database design is the foundation
of good applications. It provides a blueprint to build the tables and relationships that are required in a
database application. Second, different people — managers, administration staff and programmers —
view data differently. Managers see database applications from a decision-making perspective, while
administration staff are more concerned about its ease of use. Programmers often think about design
simplicity without considering decision making and ease of use capabilities. If there is a good database
model, it does not matter that people have different views, because these views will all be encapsulated
in the database model.
Database modelling often starts with a conceptual model that provides a global view of the data. This
is usually an organisation-wide view of the data from the perspective of senior managers, and will be
referred to later in the chapter as the concept of a top-down view. The most widely used database model
is the entity–relationship model. The entity–relationship model is a database model that logically and
graphically depicts relationships between entities and attributes, and between entities and entities. Data-
base modelling is the first step in developing a database, before designing and implementing. It uses ER
diagrams to develop the blueprint for the design.

Entity–relationship models
Entity–relationship models are depicted by entity–relationship diagrams (ER diagrams) and provide a
conceptual view that incorporates:
•• entities
•• attributes
•• relationships.
Entities in an ER diagram represent real-world things or objects such as employees, types of
employees, customers, types of customers, suppliers and types of suppliers. Entities usually correspond
to an entire table rather than a row in a table of a relational database. They are usually represented by
rectangles. Each entity will have attributes.
Attributes are the characteristics of entities. For example, a customer may have attributes including
first name, last name, address, telephone number and email. Figure 3.11 shows the attributes of the
customer entity using two representations: Chen’s model and the crow’s foot model. Some conceptual
material is best explained through Chen’s model, while the crow’s foot model is more useful for imple-
mentations. These models are discussed in greater detail below.
Relationships are associations between entities. Cardinality among the entities describes the
relationship as 1:1 (one-to-one), 1:N (one-to-many) or M:N (many-to-many). While cardinality
describes the relationship between entities, business rules express the number of entity occurrences
associated with one occurrence of a related entity. A business rule assigns a specific value to the
cardinality.
For instance, the entity–relationship diagram in figure 3.12 depicts the relationship between a sales-
person and a customer of a particular organisation. The cardinality shows that in this organisation each
salesperson has many customers but each customer has only one salesperson. The business rules rep-
resent the number of occurrences in the related entity. In figure 3.12, each salesperson can have up to
and no more than ten customers. Similarly the business rule of (1,1) written next to the customer indi-
cates that each customer must have one and only one salesperson.

CHAPTER 3 Database concepts I 105

Chen’s model

Customer

First name Email

Last name Address

The crow’s foot model

Customer

First name
Last name
Address
Email

FIGURE 3.11 Entities in Chen’s model and the crow’s foot model

Cardinalities

1 N

Salesperson Customer

(1,1) (1,10)

Connectivities

FIGURE 3.12 An entity–relationship model

The business rules show the minimum and maximum number of entities that can be involved in a
relationship. An example illustrating this is the relationship between the entities manager and company
car. This may be written as (0,1): many managers may not be given a company car so 0 is the minimum
and 1 is the maximum as a manager will only be assigned one company car at a time. So, the minimum
and maximum of this relationship is 0 and 1 respectively.

106 PART 2 Systems characteristics and considerations

 To illustrate how this ER diagram can be applied to relational databases, consider the table structure
of the ER diagram in figure 3.12. It puts the operationalisation of Chen’s model into a relational database
context. The attributes in figure 3.12 have been assumed for the purposes of illustrating the link between
the salesperson and customer. Organisations are likely to have their own attributes that may not be the
same as those in figure 3.12.
The tables are not physically connected; instead, the connections exist through matching data
stored in each table. In the example in figure 3.13, the customer is linked to the salesperson through
the field ‘Salesperson_code’. This connection allows users to match customers to salespersons
through the customer data stored in one table or the salesperson data stored in another table. For
instance, you can easily determine that Swati Takutai’s salesperson is Ashley Smith Brown because
the ‘Salesperson_code’ in the customer table is ‘9001’, which references Ashley Smith Brown in
the salesperson table. Similarly, you can determine that Peter Thomas Burkitt, salesperson 9002,
has two customers — David Smith and Michael Burford — and so on. The point is that, although
the tables are independent, it is easy to connect data between the tables and answer different ques-
tions that might be asked of the data. For example, we can find out the name and phone number
of Michael Burford’s salesperson, even though that information is not contained in the customer
table.

Table: Customer

Customer_code Customer_name Customer_address Customer_phone Salesperson_code

1000 Swati Takatai 2 Apple Street, Melbourne, VIC 03  1234  5678 9001

1001 David Smith 6 Banana Street, Melbourne, VIC 03  9876  4321 9002

1002 John Brown 9 Carrot Street, Melbourne, VIC 03  5678  3456 9003

1003 Mary Jones 3 Durian Street, Melbourne, VIC 03  2376  1048 9004

1004 Michael Burford 5 Enchilada Lane, Melbourne, VIC 03  9386  9191 9002

Table: Salesperson

Salesperson_code Salesperson_name Salesperson_initials Salesperson_phone

9000 Andrew Fred Davis AFD 03  8344  3677

9001 Ashley Smith Brown ASB 03  8344  3678

9002 Peter Thomas Burkitt PTB 03  8344  3679

9003 William Edward Chong WEC 03  8344  3680

FIGURE 3.13 A simple relational database linking customer and salesperson tables

Figures 3.11 to 3.13 show how a database designer can use the ER diagram representation of a specific
relationship between real-world entities and apply it to an implementable database model, which in
this case is the relational database. The operationalisation of an ER diagram is the concern of database
design. This is outlined in the next section on database design.
Chen’s model uses rectangles to depict entities, diamonds to depict relationships and circles (see
figure 3.11) to depict attributes. Cardinalities are written next to the entities. The other established

CHAPTER 3 Database concepts I 107

version of the ER diagram is the crow’s foot model, in which rectangles represent the entities, which
are related by lines with single and multiple prongs to show the cardinalities. Figure 3.14 summarises
the shapes used for each of the simple Chen’s model and crow’s foot model.

Chen’s Crow’s foot

Entity

Relationship line

Relationship

One (1) symbol 1

Many (N) symbol N

Composite entity

FIGURE 3.14 Entity–relationship model shapes

In summary, ER diagrams provide a logical and graphical representation of the entities within an
organisation and the relationships among those entities. They serve as database models that can be used
to construct databases that adhere to the organisation’s business rules and record the transactions among
the entities.
Developing a conceptual model entity–relationship diagram
(ER diagram)
The development of an ER diagram is an iterative process involving four steps.
1. Develop a general narrative of the organisation’s operations including the business process, policies
and business rules.
2. Construct the ER diagram by identifying the internal and external entities and the relationships among
them from the narrative in step 1. Cardinalities and business rules can also be assigned based on the
narrative.
3. Have the ER diagram reviewed by each area of the organisation with ownership of the operations,
policies and processes.
4. Make the necessary modifications to incorporate any newly discovered entity relationship components.
This four-step process should be repeated until the designers and users agree that the ER diagram is
complete and represents the relationships and the rules that govern the organisation’s entities.
These steps are performed by systems analysts and database designers; however, it is important for
an accountant to be involved in reviewing the ER diagram to ensure that the business rules reflect how
the organisation works. Therefore, understanding how to read and interpret ER diagrams is critical for
accountants.
The four-step process will be demonstrated in the section on database design using an example of
employees that charge their time to projects. Once a conceptual model is created, the designer can turn
this model into an implementation model through resolving all many-to-many relationships into one-to-
many relationships and ensuring all primary-foreign keys are implemented.

108 PART 2 Systems characteristics and considerations

3.6 Database design
LEARNING OBJECTIVE 3.6 Critically describe how relationships in a database model reflect how the
organisation works.
The table is the basic building block in database design. Table structures must be efficient to allow fast
and error- and duplication-free flow of information.

Conceptual model entity–relationship diagram

In database design, tables are created to represent every internal and external entity and their attributes.
As stated earlier, examples of entities are the salesperson, manager, supervisor, customer, type of cus-
tomers, supplier and type of suppliers to the organisation. Projects are also entities; in the example
looking at employees charging time to projects, employees and projects are the entities we need in our
database design, as these are the entities about which we want to record information. We use the singular
for the names of the entities such as ‘customer’ or ‘project’, not ‘customers’ or ‘projects’. We also name
the association between them in the diamond as ‘charges time to’. Try to name the association (the
words in the diamond) from left to right so that it makes grammatical sense.
External users External users External users External users

External model External model External model External model

Conceptual model
Entity–relationship diagram

Implementation model
Entity–relationship diagram normalised

FIGURE 3.15 Conceptual model development

Using the example of employees that charge their time to projects on consulting jobs, we can develop
the conceptual model in figure 3.15 and construct a table structure. Both employees and the projects they
work on are entities that we wish to record information about. This is shown in figure 3.16.

Charges
Employee Project
time to

FIGURE 3.16 Employee project ER diagram

CHAPTER 3 Database concepts I 109

 The ER diagram shows that the employee charges time to different projects. The employee and the
project are entities and the relationship between them is the charging of the time. Attributes have not
been given to the entities yet; this can be done later. This relationship can be implemented differently
depending on the business rules in the organisation. As shown in figure 3.17, the relationship can be
implemented in four different ways.
N 1

Charges
Employee Project
time to

1 N
Charges
Employee Project
time to

1 1

Charges
Employee Project
time to

N M

Charges
Employee Project
time to

FIGURE 3.17 Employee project ER diagram with different organisational business rules

Each of these relationships is a conceptual model and means different things with regard to the organ-
isation’s operations.
Take the first line as shown in figure 3.18. The relationship can be read from both sides of the dia-
gram. Reading the relationship from left to right, as the arrow in figure 3.18 indicates, take one of the
first entity and relate it to the number of the second entity. Therefore:

ONE Employee can charge time to ONE Project.

You must always consider one (singular) of the first entity and then look at how many of the second
entity that relates to. The ONE next to the second entity means that an employee can charge time to (or
work on) only ONE project.

N 1

Charges
Employee Project
time to

FIGURE 3.18 Employee project ER diagram with N:1

110 PART 2 Systems characteristics and considerations

 Reading this relationship from the other direction (see figure 3.19), take one of the first entity, which
is project this time, as we are reading the relationship from right to left. Then relate this one project to
how many occurrences of employee. Therefore:
ONE Project can have MANY Employees working on it.
Figure 3.19 shows taking one of the first entity, project, and relating it to the N on the other side of the
diagram, which is written next to the employee entity.

N 1

Charges
Employee Project
time to

FIGURE 3.19 Employee project ER diagram with 1:N (on different entities)

Overall, the relationship in figures 3.18 and 3.19 is shown in figure 3.20.
N 1

Charges
Employee Project
time to

FIGURE 3.20 Employee project ER diagram with 1:N (no arrows)

The relationships in this diagram are read as:

ONE Employee can charge time to ONE Project.
ONE Project can have MANY Employees working on it.
The business logic underlying this relationship is that an employee can work on only one project at
a time, yet a project can have many employees working on it at any one time. If the organisation wants
an employee to be able to work on more than one project, this database model is not suitable. This is an
example of a one-to-many relationship (1:N).
The next conceptual model with different business rules from figure 3.17 is shown as figure 3.21. Notice
that the one and the many are on different sides of the entities than in figure 3.18. The different placement
of the one-to-many (1:N) means that the relationship between the two entities will be different.

1 N

Charges
Employee Project
time to

FIGURE 3.21 Employee project ER diagram with 1:N (project side)

CHAPTER 3 Database concepts I 111

Reading figure 3.21 from left to right, take one employee and relate it to the number of occurrences of
projects:
ONE Employee can charge time to MANY Projects.

Reading figure 3.21 from right to left, the bottom arrow on the figure:

ONE Project can only have ONE Employee working on it.

So, the logic underlying this relationship is that an employee can work on many projects but a project
can have only one employee working on it at a time. If this does not match how the organisation works,
this is not a suitable model of the data relationships.
The third conceptual model shows the relationship in figure 3.17 as figure 3.22.

1 1

Charges
Employee Project
time to

FIGURE 3.22 Employee project ER diagram with 1:1 relationship

This is a one-to-one relationship (1:1) as there is one beside both entities. The relationship reads
from left to right:

ONE Employee can charge time to ONE Project.

Reading the relationship from right to left:

ONE Project can have only ONE Employee working on it.

So, figure 3.22 shows quite a restrictive relationship in that an employee can work on only one pro-
ject and a project only can have one employee working on it at any time. One-to-one (1:1) relation-
ships are reasonably rare. However, if the organisation is taking over a database from another
organisation, it needs to ensure that the relationships between the entities match how the organisation
works. Accepting a 1:1 relationship between the employee and the project entity in a database but
allowing multiple employees to work on one project in practice means the database would be unable
to record data in the way the organisation works. This highlights the importance of the relationships
between entities and of not implementing any database design before determining if it matches how
the organisation operates.
Finally, in figure 3.23 we have a conceptual model of a many-to-many relationship (M:N). To read
this relationship from the left to the right:

ONE Employee can charge time to MANY Projects.

Reading the relationship sentence from right to left:

ONE Project can have MANY Employees working on it.

112 PART 2 Systems characteristics and considerations

 N M

Charges
Employee Project
time to

FIGURE 3.23 Employee project ER diagram with M:N relationship

This process of identifying the entities and the relationships between the entities continues until all
entities and relationships are identified. This process would normally be undertaken by systems analysts
and database designers in conjunction with a team of users of the system. After the identification pro-
cess is complete, the relationships between the entities should be verified with a range of employees in
the organisation. This ensures that the identified relationships are correct for the organisation. One such
employee involved in verifying the relationships is the accountant, and hence the importance of account-
ants understanding what these relationships mean.
After the relationships in the conceptual model have been identified and verified, they can be converted
into an implementation model and logically implemented in a database system. Figure 3.24 summarises
the different conceptual model relationships that can be implemented between two entities, depending
on how the business operates.

N 1 An employee can work on only one project.

So when a project is finished they will be
Charges
Employee Project allocated another project. However, a project
time to
can have more than one employee on it
(many employees).

1 N
An employee can work on many projects.
Charges
Employee Project However, a project can have only
time to
one employee on it.

1 1
An employee can work on only
Charges
Employee Project one project. A project can have only
time to
one employee on it.

N M

Charges An employee can work on many projects.

Employee Project
time to A project can have many employees on it.

FIGURE 3.24 Summary of employee project conceptual model ER diagrams with different organisational
business rules

CHAPTER 3 Database concepts I 113

 The next section discusses how 1:1 (one-to-one), 1:N (one-to-many) and M:N (many-to-many)
relationships need to be implemented in computer database packages. This is moving from the
conceptual model with the logical representation of the data to the implementation model shown in
figure 3.25.

Implementation model
External users External users External users External users

External model External model External model External model

Conceptual model
Entity–relationship diagram

Implementation model
Entity–relationship diagram normalised

FIGURE 3.25 Implementation model development

Implementing relationships
Figures 3.26, 3.27, 3.30 and 3.31 show the relationships between the project table and employee table
from figures 3.3 and 3.4. Note that the project number has been chosen as the primary key (unique iden-
tifier) in the project table and the employee number has been chosen as the primary key in the employee
table. Each of the tables includes attributes as illustrated in figure 3.3.

Implementation model — implementing one-to-many (1:N)

relationships
To implement the 1:N (one-to-many) relationship as shown in figure 3.26 and figure 3.27, the general
rule is the primary key of the one becomes the foreign key of the many. A foreign key is an attribute
whose values must match the primary key in another table. Therefore, for figure 3.26 the primary key
of the one is the primary key of the project table (Proj_num) and would become the foreign key of the
many (the employee table).

114 PART 2 Systems characteristics and considerations

 N 1

Charges
Employee Project
time to

FIGURE 3.26 Employee project ER diagram with 1:N

1 N

Charges
Employee Project
time to

FIGURE 3.27 Employee project ER diagram with 1:N (project side)

This results in figure 3.28, the implementation model database implementation of figure 3.26. From
figure 3.28 we can see that project number now becomes the foreign key of the employee table. As an
employee can work on only one project, having the project number in the employee table is correct. The
foreign key project number in the employee table indicates that it is a primary key in another table. A
foreign key is also indicated by a dashed underline. Remember primary keys are shown using a bold
underline.
For figure 3.27, to implement the database, we need the primary key of the one (which is the primary
key of the employee table, Emp_num) to become the foreign key of the many (the project table) in
figure 3.29. This makes sense as a project can have only one employee working on it, and the employee
can be indicated in the project table against the project. The details of the employee are not transferred
to the project table because, if they are working on multiple projects, their name and other details would
be duplicated, potentially causing update and modification data anomalies and data integrity issues as
discussed earlier in the chapter (i.e. all instances of an employee’s details would need to be updated if
any changes were made to those details). As the structure stands, employee details are contained in the
employee table. Any updates would need to be made once and once only in the employee table. This
means that data redundancy and anomalies are avoided.

Project table

Proj_num Proj_name Proj_start Proj_budget

1 Oceania 01/01/2015 $10  000

2 Parade 01/04/2015 $30  000

3 Pukenamu 01/12/2014 $50  000

Employee table

Emp_num Emp_name Proj_num

101 Michael Burford 1

105 Brett Micawber 1

110 Phil Musick 2

FIGURE 3.28 Database implementation of employee project ER diagram with 1:N

CHAPTER 3 Database concepts I 115

 Project table

Proj_num Proj_name Proj_start Proj_budget Emp_num

1 Oceania 01/01/2015 $10  000 101

2 Parade 01/04/2015 $30  000 105

3 Pukenamu 01/12/2014 $50  000 110

Employee table

Emp_num Emp_name

101 Michael Burford

105 Brett Micawber

110 Phil Musick

FIGURE 3.29 Database implementation of employee project ER diagram with 1:N (project side)

Implementation model — implementing 1:1 (one-to-one) relationships

In implementing a one-to-one relationship (1:1) as shown in figure 3.30, the general rule is to anticipate
which side is most likely to become many in the future and implement as though it was a one-to-many
(1:M) relationship now. So, the database for the 1:1 relationship would be implemented as shown in
figure 3.30 if you thought that a project could have multiple employees working on it in the future. Or,
you could implement it as shown in figure 3.29 if you thought that employees would be more likely to
work on multiple projects in the future.

1 1

Charges
Employee Project
time to

FIGURE 3.30 Employee project ER diagram with 1:1 relationship

Implementation model — implementing M:N (many-to-many) relationships

The implementation of a many-to-many (M:N) relationship as shown in figure 3.31 is probably the
most complex but by far the most common in organisations. This relationship is shown as M:N not
as N:N.

M N

Charges
Employee Project
time to

FIGURE 3.31 Employee project ER diagram with M:N relationship

116 PART 2 Systems characteristics and considerations

 The relationship diamond between the two entities needs to be converted to a composite entity
holding the primary keys of each of the entities as shown in figure 3.32. A composite entity is
shown as a rectangle with a diamond inside it. That is, the relationship (diamond) becomes an entity
(rectangle).

Project table

Proj_num Proj_name Proj_start Proj_budget

1 Oceania 01/01/2015 $10  000

2 Parade 01/04/2015 $30  000

3 Pukenamu 01/12/2014 $50  000

Employee table

Emp_num Emp_name

101 Michael Burford

105 Brett Micawber

108 David Smith

110 Phil Musick

112 Anne Wyatt

Employee project table

Proj_num Emp_num

1 101

1 105

1 110

2 101

2 108

3 105

3 110

3 112

FIGURE 3.32 Database implementation of employee project ER diagram with M:N relationship

This linking entity (the employee project table) has the primary keys of both the tables attached
to it (shown by the bold underlines), to enable the implementation of the relationship of employees
being able to charge time to many projects and projects being able to have many employees work on
them. The primary key of this linking entity is the primary key of each of the tables attached to it.
So, the primary key is a composite primary key, as we discussed earlier in the chapter, made up of
the attributes project number and employee number, Proj_num, Emp_num. This new composite entity
and the breaking of the many-to-many relationship into two one-to-many relationships is shown in
figure 3.33.

CHAPTER 3 Database concepts I 117

 1 N N 1

Charges
Employee Project
time to

FIGURE 3.33 Employee project ER diagram with M:N relationship broken into two 1:N relationships

This splitting of the conceptual model many-to-many relationship into two one-to-many
relationships needs to occur so that the relationships can be implemented in a computerised database
package.
To show that a many-to-many relationship has been broken down into two one-to-many relationships
we can use the example of projects and employees. In the format of the many-to-many relationship
shown in figure 3.31, if we trace onto this relationship the data from figure 3.32, we get the situation
shown in figure 3.34.

M N

Charges
Employee Projects
time to

Employee table Project table

Emp_num Emp_name Proj_num Proj_name Proj_start Proj_budget

101 Michael Burford 1 Oceania 01/01/2015 $10  000

105 Brett Micawber 2 Parade 01/04/2015 $30  000

108 David Smith 3 Pukenamu 01/12/2014 $50  000

110 Phil Musick

112 Josephine Wyatt

FIGURE 3.34 Project employee data

Figure 3.35 shows the project employee assignments in a many-to-many relationship. The assignments
come from the employee project table in figure 3.32. The many-to-many relationship in figure 3.34 has
not been implemented as yet. We can see, given figure 3.32, that project number 1 has an arrow to
employee number 101, the first row in the employee project table in figure 3.32. Project number 1
also has a line to employee number 105, the second row in figure 3.34, and also to employee number
110. Project 2 has an arrow to employee number 101 (fourth line in figure 3.32) and also to employee
number 108.
So, we can see that project 1 has multiple employees charging time to it, in particular, employee
numbers 101, 105 and 110. Also, employee number 101 works on both project 1 and project 2.
The semantics or logic in figure 3.34 is impossible to implement in a database structure, so
the many-to-many relationship is broken down into two one-to-many relationships as shown in
figure 3.35.

118 PART 2 Systems characteristics and considerations

 1 N N 1

Charges
Employee Project
time to

Employee table Employee project table Project table

Emp_num Emp_name Emp_num Proj_num Proj_num Proj_name Proj_start Proj_budget

101 Michael Burford 101 1 1 Oceania 01/01/2015 $10  000

105 Brett Micawber 105 1 2 Parade 01/04/2025 $30  000

108 David Smith 110 1 3 Pukenamu 01/12/2024 $50  000

110 Phil Musick 101 2

112 Josephine Wyatt 108 2

105 3

110 3

112 3

FIGURE 3.35 Employee project and employee project mapping table

Figure 3.36 shows that the many-to-many relationship can now be implemented as two one-to-many
relationships. So, we know there are four relationships in the logical model as shown in figure 3.36.

1 N N 1

Charges
Employee Projects
time to

FIGURE 3.36 Employee to employee/project (left-hand side) and employee/project to project

(right-hand side)

Reading the relationships marked by arrows in figure 3.36 from the left:

ONE Employee can have MANY Employee/Project charges.

And from the right:

ONE Employee/Project charge can belong to only ONE Employee.

Therefore, the relationship goes from the employee entity to the employee/project entity and shows
the allocation of employees to projects. It shows that an employee can work on many employee/projects

CHAPTER 3 Database concepts I 119

(e.g. employee 101 works on employee/projects 1 and 2). But any employee/project charges — for
example, the first one in the employee/project table of employee number 101 and project number 1 —
must go back to only one row in the employee table, in this case to employee number 101.
Likewise, the second half of the relationship between project and employee/project can be read from
left to right:
ONE Employee/Project relates to only ONE Project.
And from right to left:
ONE Project relates to MANY Employee/Project allocations.
This exhibits the one-to-many status of this relationship.
Overall, we need to build database models that are conceptual and that provide a logical represen-
tation, in graphical form, of the complexities of real-world data structures. These database models show
us how an organisation works (i.e. the business rules that apply to the organisation). Once we have
created the conceptual model, this needs to be converted to an implementation model that is able to be
installed on a computer. This implements all the necessary keys and resolves the many-to-many relation-
ships in the conceptual model into two one-to-many relationships in the implementation model. As
described in AIS Focus 3.2, it is very important to understand what the database model means in terms
of how the business works. If we implement the database using relationships other than those relevant to
how the organisation works, the organisation’s transactions cannot be recorded.
The database designer can also depict the data structures, relations, characteristics and constraints of
the database design in a database model. Hence, a database model is a communication tool that creates
improved understanding of an organisation’s existing database, or provides the blueprint for developing
new database structures.
As outlined above, the relationships that exist in an ER diagram are a function of how the business
works. Choosing a database design that does not allow for many-to-many relationships when the busi-
ness uses them will have far-reaching implications for the information systems built to use the database.
Figure 3.37 summarises the four ways a relationship can be implemented, the corresponding database
design and what each implies for business rules.

AIS FOCUS 3.2

Tax Disputes Limited

The accountant at Tax Disputes Limited — a tax advisory services business — wanted to create a mini
information system using the desktop software Microsoft Access. By using the techniques outlined in
this chapter on database concepts, they will save themselves many false starts if they have some basic
understanding of database design.
Even though they may have a database professional creating the database, the accountant at Tax
Disputes Limited will need to understand that the database professional will be using the top-down
approach described in this chapter. The database professional will first create a data model using
an entity–relationship diagram. To do this, they will need to consider the important entities required
to record data on the business. They will then need to consider how these entities are related using
relationships.
The database professional will ask questions of the accountant about how entities within the Tax Dis-
putes Limited business are related. At times, the database professional may seem to ask certain ques-
tions twice, but the accountant will realise that the database professional is looking at the relationships
between entities from both directions.
This knowledge of what the database professional is asking ensures that the accountant can consider
and answer the questions carefully and fully. Then, when the data model (entity–relationship diagram)
is complete, the accountant can evaluate it to ensure that it accurately represents how Tax Disputes
Limited’s business works before the relationships are created in the software program and the organ­
isation’s valuable data is loaded into the system.

120 PART 2 Systems characteristics and considerations

 Model Database design Business rules

Employee–Project Project table An employee can

N:1 Proj_num Proj_name Proj_start Proj_budget work on only one
N 1 project.
Charges Employee table
Employee Project A project can have
time to Emp_num Emp_name Proj_num
more than one
employee working on it.

Employee–Project Project table An employee can

1:N Proj_num Proj_name Proj_start Proj_budget work on many
1 N Emp_num projects.
Charges
Employee Project
time to Employee table A project can have
Emp_num Emp_name only one employee
working on it.

Employee–Project As for either model above, depending on which An employee can

1:1 side is more likely to become many in the future. work on only one
1 1 project.
Charges A project can have
Employee Project
time to only one employee
working on it.

Employee–Project Project table An employee can

M:N Proj_num Proj_name Proj_start Proj_budget work on many
1 N N 1 project/employee
Charges Employee table assignments.
Employee Project
time to Emp_num Emp_name A project/employee
assignment can relate
Project/Employee table to one employee only.
Proj_num Emp_num A project can
have many
project/employee
assignments.
A project/employee
assignment can relate
to only one project.

FIGURE 3.37 Summary of database models, design and business rules

Top-down versus bottom-up database design

The entity–relationship diagram looks at entities and their relationships from an overall perspective.
So it is a strategic or top-down way of viewing the organisation and developing a database model.
Normalisation, the technique detailed in chapter 4, is the bottom-up view of designing a database. In
reality, when designing databases, both techniques will be used. The entity–relationship diagrams ensure
that upper-level strategic objectives of the organisation are included in the database model. So the mat-
erials in this chapter are valuable in their own right, even without normalisation. However, normalisation
ensures that the lower-level operational aspects are included in the database model as the normalisation
process starts with the tables, forms and data of the organisation. Once each technique is applied, they
are reconciled to ensure an organisation-wide database model is created that includes strategic objectives
as well as operational data.
Once the table structure has been defined, normalisation will be used to assign attributes to entities. Nor-
malisation is the process of assigning attributes to entities to eliminate repeating groups and data redun-
dancies. The goal is to form tables representing entities that promote structural and data independence.

CHAPTER 3 Database concepts I 121

Therefore, normalisation maximises the efficiency of the structure. Given that many table structures will
provide the information required by the organisation’s ER diagrams, normalisation maximises the efficiency
of the structure by reducing data redundancies, eliminating data anomalies and producing a set of controlled
redundancies to link tables that provide the most flexible system for the organisation.
Chapter 4 will take a table and illustrate both the need for normalisation and the normalisation process.
Following discussion on the data redundancy problems of the table, normalisation will be applied to come
up with a solution that resolves those problems. Note that there are a number of forms of normalisation
from first normal form (1NF) to fifth normal form (5NF), with a special case of 3NF, so six normal forms
altogether. However, we will concentrate only on up to third normal form (3NF) as this is all that business
applications require. Each of the first three forms of normalisation is explained in the next chapter.

SUMMARY
3.1 Explain the role of databases in decision making and reporting systems.
Company managers and employees require good information to make strategic and operational decisions.
Information is accurate, timely and relevant only if data are captured, stored and managed efficiently and
effectively in a database. Database concepts such as database modelling, design and implementation
help to capture, store, manage and manipulate data efficiently and effectively.
3.2 Define the function of a database and the concept of database systems.
A relational database is a collection of tables and each table describes an entity about which you want to
record data. A table is a collection of columns or attributes that describe an entity. A record is a row in
a table that describes one occurrence of an entity. Every table in a database must have a unique primary
key, which is an attribute that uniquely identifies a particular row in a table.
3.3 Demonstrate the concept of data redundancy and the advantages of databases.
When data such as the address of a customer is repeated in a database, database redundancy has occurred.
This means that the address of the customer needs to be updated in multiple locations. The advantage of a
database is that data can be structured in such a way that the customer address appears only once in the data-
base. It therefore needs to be updated only once in the database should it change and so is always up to date.
3.4 Discuss database systems and justify use of the relational database.
A database system is a collection of elements that allow the capture, storage, management and use of data
within a database environment. These elements include hardware, software, people, procedures and data.
In general, data are stored in a central location in computer and storage hardware that is managed by soft-
ware that incorporates a DBMS. Database administrators and programmers establish procedures or busi-
ness rules for the organisation to collect, store, manage and use the data for decision making and reporting.
3.5 Apply database modelling and exercise judgement to develop database models using
entity–relationship diagrams.
Database modelling involves developing conceptual models that provide a logical representation, in
graphical form, of the complexities of real-world data structures. A database designer can also depict the
data structures, relations, characteristics and constraints of the database design. A database model is a
communication tool that creates improved understanding of an organisation’s database, or provides the
blueprint for developing new database structures. Database modelling is the first step before designing
and implementing a database and uses ER diagrams to develop the blueprint.
3.6 Critically describe how relationships in a database model reflect how an organisation
works.
The conceptual database models or ER diagrams can be read from left to right and vice versa to find out
how the relationships in the database work. This understanding can be compared to how the organisation
works to ensure a match.

122 PART 2 Systems characteristics and considerations

KEY TERMS
Attributes Characteristics of entities.
Cardinality The specific number of allowed entity occurrences associated with a single occurrence of
the related entity by assigning a specific value to connectivity.
Client–server system A computing model that is based on distributing functions between two types of
independent and autonomous processes: clients and servers.
Composite key A combination of more than one attribute to form one primary key. It indicates an
M:N (many-to-many) relationship between the columns.
Conceptual models Models that focus on a logical view of what is represented in the database.
Controlled redundancies Redundancies that are allowed for the convenience of structuring data, data
manipulation or reporting.
Data Raw facts relating to or describing a single business transaction or event.
Data anomalies Inconsistencies or errors that exist in a database because of entry or changes.
Data integrity Consistent and correct representation regardless of where data are sourced from within
a file system.
Data redundancy The situation where the same data are recorded and stored in multiple locations,
which can lead to data inconsistency and anomalies.
Database A shared computerised structure that captures, stores and relates data.
Database administrator A person who controls access by users to the database, maintains the data
dictionary and oversees backup and recovery in the DBMS.
Database management system (DBMS) A group of programs that manipulate the database and
provide the interface between the database and the user as well as other application programs.
Database models Diagrams of data entities and their relationships.
Database system A system of hardware, software, people, procedures and data that allow the capture,
storage, management and use of data within a database environment.
Deletion anomalies Data anomalies that occur when the deletion of data about an entity inadvertently
deletes data about another entity.
Entities Representations of real-world things or objects that are involved in a process and correspond
to a table in a relational database.
Entity–relationship model A data model that graphically depicts relationships between entities and attributes.
External models Models that relate to the end-users’ views of data.
Field A characteristic of a record that contains data that have a specific meaning.
File A collection of records that are related.
Foreign key An attribute whose values must match the primary key in another table.
Hardware Physical devices including the computer and network.
Implementation models Models that show how the data are represented in the database, including the
structures implemented.
Information Data or facts that are processed in a meaningful form.
Insertion anomalies Data anomalies that occur when new data are entered into the file and not all
occurrences are updated.
Logical representation A model that represents data and their relationships independent of
hardware and software. This representation can then be used to select a database management
system (DBMS).
Many-to-many relationship (M:N) A relationship between two entities in which the cardinality of
both entities in the relationship is many.
Modification anomalies Data anomalies that occur when a field value is changed and not all
occurrences are updated.

CHAPTER 3 Database concepts I 123

Normalisation A set of rules and a process of assigning attributes to entities to eliminate repeating
groups and data redundancies, and to form tables representing entities that promote structural and
data independence.
One-to-many relationship (1:N) A relationship between two entities in which the cardinality of one
entity in the relationship is one and the other entity’s cardinality is many.
One-to-one relationship (1:1) A relationship between two entities in which the cardinality for each
entity is one.
Operating system Computer programs that control hardware to interface with software application
programs.
Physical representation A model that presents all the database storage details including all
specifications for hardware and software.
Primary key An attribute (or column) that uniquely identifies a particular object (or row).
Procedures The instructions and rules that govern the design and use of the software outside
programming.
Record A connected set of fields that describes a person, place or thing.
Relational database A database that stores data in a number of tables.
Software Computer programs that are written in programming languages or code that instruct the
operations of a computer.
Structural independence A data attribute that exists when changes in the database structure do not
affect access.
Structured query language (SQL) A database query language that allows the user to specify what
must be done without having to specify how it is to be done.
Table A collection of columns (attributes) and rows (objects) that describe an entity.

DISCUSSION QUESTIONS
3.1 What advantages do databases offer for decision-making and reporting processes? (LO1)
3.2 Define the operation of a relational database. Why has it taken over as the optimal
structure to implement in organisations? (LO2, LO4)
3.3 How do the characteristics of poor file system design limit their usefulness for
decision making and reporting? (LO3)
3.4 Describe the elements of a database system, including the DBMS. (LO4)
3.5 Explain why database modelling is performed. How is it performed? (LO5)
Questions 3.6 to 3.11 relate to figure 3.38.
3.6 Explain where this diagram shows that a supplier can supply many DVD titles. (LO6)
3.7 Explain where this diagram shows that a DVD title can come from many suppliers. (LO6)
3.8 Explain where this diagram shows that a DVD title can have many DVD copies. (LO6)
3.9 Explain where this diagram shows that a DVD copy relates to one title only. (LO6)
3.10 Explain where this diagram shows that a DVD copy can be rented to one customer
at a time. (LO6)
3.11 Explain where this diagram shows that a customer can rent many copies of a DVD. (LO6)

124 PART 2 Systems characteristics and considerations

 1 N

Has
DVD title DVD copy
many

N N

Is Is
sourced rented
from to

M 1

Supplier Customer

FIGURE 3.38 DVD store rental database (excluding purchase, supplier payment, rental payment and
receipt items)

Questions 3.12 and 3.13 relate to the DVD store model entity–relationship diagram in figure 3.38 and
the DVD store tables in figure 3.39.

DVD Title

DVD Title num DVD_Title DVD_topic DVD_length

1 Angel fish Fish 1.30

2 Tai Chi Panda Panda 2.30

3 Happy Penguin Penguin 1.36

DVD Copy

DVD_Copy_num DVD_Title_num Customer_num Date/time_rented

101 1 62 01/01/2015 6pm

201 2 84 01/04/2015 8pm

301 3 95 01/12/2014 8pm

FIGURE 3.39 DVD store tables

3.12 Explain what DVD_Title_num in the DVD Copy table is and what purpose it serves. (LO6)
3.13 Explain what Customer_num in the DVD Copy table is and what purpose it serves. (LO6)

CHAPTER 3 Database concepts I 125

Questions 3.14 and 3.15 relate to figure 3.40.
3.14 Using the entity–relationship diagrams in figure 3.40, discuss the relationship between the two
entities. (LO6)
(a) The Employee–Laptop relationship.
(b) The Customer–Sales order relationship.
(c) The Employee–Company car relationship.

Is
Employee Laptop
assigned
(1, 1) (1, 1)

Customer Places Sales order

(1, 1) (1, N)

Is provided
Employee Company car
with
(1, 1) (0, 1)

FIGURE 3.40 Entity–relationship diagrams

3.15 Change the entity relationships in figure 3.40 and discuss what your changes mean for the
business. (We have provided an example in figure 3.41, which shows a change in the entity
relationship between Employee and Company car.) (LO6)

Is provided
Employee Company car
with
(1, 1) (1, N)

Is provided
Employee Company car
with
(1, N) (0, 1)

Is provided
Employee Company car
with
(0, N) (0, 1)

FIGURE 3.41 Entity–relationship diagrams (with changes)

126 PART 2 Systems characteristics and considerations

SELF-TEST ACTIVITIES
3.1 Which of the following statements is false? (LO1)
(a) Good decision making and reporting are vital for organisational performance.
(b) Good decision making and reporting require accurate information.
(c) Accurate information comes from quality data capture, storage and use.
(d) None of the above.
3.2 The limitations of poor file systems come from: (LO3)
(a) data management.
(b) structural independence.
(c) database redundancy.
(d) all of the above.
3.3 Which of the following statements is true? (LO5)
(a) Implementation models show how the data are represented in the database.
(b) Conceptual models focus on what is represented in the database.
(c) Implementation and conceptual models can be either logical or physical.
(d) All of the above.
3.4 The advantage of a relational database is: (LO4)
(a) structural dependence.
(b) its powerful and flexible query language.
(c) a data dictionary.
(d) all of the above.
3.5 Database modelling is used for: (LO3)
(a) describing and representing complex real-world data structures.
(b) improving understanding of an organisation’s existing database.
(c) providing a blueprint for developing new database structures.
(d) all of the above.
3.6 Which of the following is a step to developing an ER diagram? (LO5)
(a) Develop a general narrative of a business’s operations.
(b) Construct a working version of the ER diagram for review by the business.
(c) Make the necessary modifications for newly discovered entities or relationships.
(d) All of the above.
3.7 Which of the following statements is true? (LO5)
(a) Normalisation should eliminate all redundancies every time.
(b) Controlled redundancies should not be allowed in database design.
(c) Data anomalies cause data integrity problems.
(d) All of the above.

PROBLEMS
3.1 Consider the following statement: ‘My manager wants to make important strategic and operational
decisions for the company, but complains about the quality of information from the files. I tell
him that he needs to understand some database concepts and invest in a database.’ Do you agree?
Provide reasons. (LO1)
3.2 Best Bikes is a large bicycle retailer that also manufactures its own brand, assembles made-to-
order bicycles from purchased components and sells fully assembled branded names. You have
been employed as a consultant to Best Bikes. Answer the following questions. (LO3, LO4)
(a) What databases are available to help Best Bikes capture, store, manage and manipulate data for
decision making and reporting?

CHAPTER 3 Database concepts I 127

 (b) How do these databases operate?
(c) What are their advantages and disadvantages?
3.3 Happy Feet Shoes is a large retailer of women’s footwear. The organisation runs a file system.
Figure 3.42 is an extract of its sales file. (LO3, LO5)
(a) Discuss the limitations of this file.
(b) Explain how a database would overcome these limitations.
(c) Illustrate your explanation by developing a database design.

Customer_name Customer_address Customer_phone Salesperson Shoe_model Shoe_amount Date

Britney Micawber 2 Apple Street, 03  1234  5678 TLM VZ4717 $29.90 20-Jul-15

Melbourne, VIC

Michelle Burford 6 Organic Street, 03  9876  4321 CBD DF3966 $79.50 30-Jul-15

Melbourne, VIC

Phillipa Musick 8 Grapefruit Street, 03  5678  3456 MTL WE9447 $50.30 4-Aug-15

Melbourne, VIC

Devine Smith 3 Echo Street, 03  2376  1048 JFK XC8187 $45.50 6-Oct-15

Melbourne, VIC

FIGURE 3.42 Extract of Happy Feet Shoes sales file

3.4 Beautiful Flowers Company has been running an outdated file system for many years. It has just
employed you as a consultant to advise it on updating its file system to a database. The business’s
managers know that the initial stages before implementation involve database modelling and
database design but they do not understand the implications of this. (LO1, LO5)
(a) Explain to the managers of Beautiful Flowers Company the objectives of database modelling in
its situation.
(b) Discuss the role and development of ER diagrams in database modelling.
(c) Explain to the company’s managers how database design will be conducted including the
function of normalisation.
3.5 Using the tables provided in figure 3.43 relating to customer and salesperson: (LO5, LO6)
(a) Prepare entity–relationship diagrams to model the relationships between salesperson and
customer as one-to-one (1:1), one-to-many (1:N) and many-to-many (M:N).
(b) Discuss and provide relationship sentences for each of the models.
(c) Implement the relationships on the entity–relationship diagram with primary and foreign keys.
(d) Which relationship between salesperson and customer do you think would be the most common
for a business to have? Give reasons why.

Table: Salesperson

Salesperson_ID Last name First name Address Telephone

Table: Customer

Customer_ID Last name First name Telephone

FIGURE 3.43 Customer and salesperson tables

128 PART 2 Systems characteristics and considerations

3.6 Using the entity–relationship diagram in figure 3.44 for the partial order entry system: (LO5, LO6)
(a) Write relationship sentences for all of the relationships.
(b) Discuss what each of the relationships means in terms of how the business works.
(c) Does the business allow partial picks (i.e. only part of the goods on the sales order to be picked)?
(d) Does the business allow partial shipments (i.e. only part of the goods that have been picked to
be shipped)?
(e) Are all shipments invoiced in full or partially (i.e. does the business allow partial invoices)?

1 N

Customer Places Sales orders

Triggers

Stock picking

Generates

1
N 1
Billed
Shipments Sales invoices
to

FIGURE 3.44 Entity–relationship diagram for the partial order entry system

3.7 Using the entity–relationship diagrams in figure 3.45, draw the diagram for the second side of the
relationship. Discuss the business set on the left-hand side and those you have chosen for the right-
hand side. (LO6)

CHAPTER 3 Database concepts I 129

 (1, N) Is
Inventory involved Sale
in

(0, 1)
Sales order Contains Inventory

(1, N)
Results
Sales order Sale
in

(0, N)
Is made
Sale Customer
to

FIGURE 3.45 Entity–relationship diagrams

3.8 Using the entity–relationship diagrams in figure 3.46, draw the diagram for the second side
of the relationship. Discuss the business set on the left-hand side and those you have chosen
for the right-hand side. (LO6)

(0, N)
Is
Sales call Customer
made by

(0, N)
Results
Sales return Sale
from

(1, 1)
Vendor Supplies Inventory

(1, N)
Vendor Supplies Inventory

FIGURE 3.46 Entity–relationship diagrams

130 PART 2 Systems characteristics and considerations

3.9 Using the entity–relationship diagrams in figure 3.47, draw the diagram for the second side
of the relationship. Discuss the business set on the left-hand side and those you have chosen
for the right-hand side. (LO6)

(1, N)
Involved
Inventory Purchase
in

(0, 1)
Purchase order Comprises Inventory

(1, N)
Results
Purchase order Purchase
in

(1, N)
Assigned
Purchase agent Vendors
to

FIGURE 3.47 Entity–relationship diagrams

3.10 Using the entity–relationship diagrams in figure 3.48, draw the diagram for the second side
of the relationship. Discuss the business set on the left-hand side and those you have chosen
for the right-hand side. (LO6)

(0, N)
Purchase Made to Vendor

(0, N)
Purchase Made by Employee

(0, N)
Results
Purchase return Purchase
from

(1, N)
Inventory clerk Updates Inventory

FIGURE 3.48 Entity–relationship diagrams

CHAPTER 3 Database concepts I 131

3.11 Using the entity–relationship diagrams in figure 3.49, provide relationship sentences for the
following. (LO5)

(1, 1) (1, N)
Painter Paints Painting

(0, N) (0, N)
Student Enrols Course

(0, N) Is (1, N)
Course taught Professor
by

(0, N) Is (0, N)
Room used Course
for

(0, N) (1, N)
Order Contains Inventory

FIGURE 3.49 Entity–relationship diagrams

3.12 Using the entity–relationship diagrams in figure 3.49, convert the conceptual model
ER diagrams into implementation model ER diagrams. You need to decide on appropriate
primary keys for the entities. (LO5)
3.13 Using the entity–relationship diagram in figure 3.50, convert the conceptual model
ER diagrams into implementation model ER diagrams. You need to decide on appropriate
primary keys for the entities. (LO5)

132 PART 2 Systems characteristics and considerations

 (1, N) (1, N)
Inventory Contained in

(1, N)

Updates

Supplies

(0, N)
(1, N)

Receiving report (1, 1)

Supplier Sends

(1, 1)

(0, N) (0, N)

(1, 1)
Contains Purchase order

FIGURE 3.50 Purchasing system

An additional activity, requiring Microsoft Access to create a database file for the DVD store used in
problems 3.5 to 3.10, is available in the learning management course.

FURTHER READING
Coronel, C & Morris, S 2014, Database systems: design, implementation, and management, 11th edn,
Cengage Learning Inc., Boston, MA.
Coronel, C, Morris, S, Rob, P & Crockett, K 2013, Database principles: fundamentals of design,
implementation, and management, 2nd edn, Cengage Learning Inc., Boston, MA.
Dunn, CL, Gerard, CJ & Grabski, SV 2005, ‘Critical evaluation of conceptual data models’,
International Journal of Accounting Information Systems, vol. 6, pp. 83–106.
Gillenson, ML 2012, Fundamentals of database management systems, 2nd edn, John Wiley and Sons
Inc., Hoboken, NJ.
Gillenson, ML, Ponniah, P, Kriegel, A, Trukhnov, BM, Taylor, AG, Powell, G 2008, Introduction to
database management, John Wiley and Sons Inc., Hoboken, NJ.
Hoffer JA, Ramesh, V & Topi, H 2013, Modern database management, 11th edn, Pearson Education,
Boston, MA.
Satzinger, J, Jackson, R & Burd, S 2012, Systems analysis and design in a changing world, 6th edn,
Course Technology, Cengage Learning Inc., Boston, MA.
Sciore, E 2009, Database design and implementation, John Wiley and Sons Inc., Hoboken, NJ.

CHAPTER 3 Database concepts I 133

SELF-TEST ANSWERS
3.1 d, 3.2 a, 3.3 d, 3.4 b, 3.5 d, 3.6 d, 3.7 c.

ACKNOWLEDGEMENTS
Problems 3.7 to 3.10: © Elsevier / Reprinted from the International Journal of Accounting Information
Systems, vol. 6, June 2005. Dunn et al., ‘Critical evaluation of conceptual data models’, pp. 83–106.
Copyright 2005, with permission from Elsevier.
Photo: © Nan104 / iStockphoto.

134 PART 2 Systems characteristics and considerations

CHAPTER 4

Database concepts II
LEA RNIN G OBJE CTIVE S

After studying this chapter, you should be able to:

4.1 understand and exercise judgement in applying the process of normalisation to achieve efficient
database designs
4.2 critically understand the different ways a business works and how this reflects in different data
structures
4.3 integrate models of a business using entity–relationship modelling and normalisation to develop an
enterprise model
4.4 justify the REA (resources–events–agents) Accounting Model as a template for modelling accounting
systems
4.5 critically differentiate the differences between REA and entity–relationship modelling
4.6 communicate and discuss the technologies relating to database implementation.
Introduction
Chapter 3 discussed the concept, importance and benefits of databases. To achieve these benefits, data-
bases need to be designed to reflect how an organisation works. Database design for corporate activities
is a highly technical activity performed by information systems experts. As an accountant, however, you
need to be aware of the process these experts perform and how to check that the outcomes reflect how
your organisation works. For a small system, you will need to ensure that the database structures cor-
rectly remove insertion, deletion and addition anomalies.
One way of designing databases is from the top down using entity–relationship modelling (ER model-
ling). This was illustrated in chapter 3. A second way of designing databases is from the bottom up using
normalisation. In designing databases, organisations generally use both methods. This chapter covers the
bottom-up method using the technique of normalisation. Normalisation, much like ER modelling, occurs
only in conjunction with the relational database. When we turn to the enterprise view in this chapter we
will see how the output of both methods (ER modelling and normalisation) is combined and reconciled
to form an enterprise model.
Overall, we need to build database models that are conceptual and provide a logical representation,
in graphical form, of the complexities of real-world data structures. Database models show us how an
organisation works, that is, the business rules that apply to the organisation. A database designer also
depicts the data structures, relationships, characteristics and constraints of their own database designs.
A database model is a communication tool that promotes improved understanding of an organisation’s
database, or provides the blueprint for developing new database structures. Database modelling is the
first step before designing and implementing a database, and uses entity–relationship diagrams (ER
diagrams).
Designing a database requires taking the database model and creating tables to represent every entity
that is important to the processes of the organisation, including all internal and external entities. Once
the table structure is defined, normalisation is used.

136 PART 2 Systems characteristics and considerations

 Normalisation is the process of assigning attributes to entities. The goal is to form tables that pro-
mote structural and data independence. In this way, normalisation enables us to create tables that are
free from data anomalies and redundancies. Therefore, normalisation maximises the efficiency of the
structure. There are a number of forms of normalisation from first normal form (1NF) to fifth normal
form (5NF). However, we will continue to only third normal form, which is sufficient for most busi-
ness applications.
Rather than using normalisation, once the tables are formed you can normalise the forms and docu-
ments used in an organisation to form the database structure. The database structure formed will be
automatic at the implementation level. The normalisation examples follow much the same format as in
chapter 3. The first table to normalise is called example A; it has data attributes that reflect how the busi-
ness works. The underlying data is then changed several times to become the normalised examples B,
C and D. These specific examples can be compared, as the attributes in each of the tables are the same,
but the normalisation process produces very different results. The reason for the differing results is that
the underlying logic (semantics) of how the data is related in examples A, B, C and D is different. How
the business works differs and this results in changes to the underlying database structures between
examples A, B, C and D.
After the normalisation process is covered, a full implementation model for an enterprise will
be developed. Also discussed in this chapter is the REA (resources–events–agents) Accounting
Model as a template for developing database models that can be used for an accounting infor-
mation system. The chapter concludes with a discussion of the technologies relating to database
implementation.
As discussed in chapter 3, an ER diagram presents the top-down view of an organisation from the
manager’s overall perspective. The technique for normalisation looks at the bottom-up view of designing
a database. However, it is important to note that, in reality, when designing databases, both techniques
will be used. ER diagrams ensure that the upper-level view of the organisation is included in the data-
base model. Normalisation ensures all of the lower-level operational aspects are also included, as nor-
malisation starts with the tables, forms and data of the organisation. Once each technique is applied, they
are reconciled to ensure that an organisation-wide database model is created that includes the upper-level
view as well as the operational data.
Once the table structure is defined, normalisation is used. Normalisation is the process of assigning
attributes to entities to eliminate repeating groups and data redundancies. The goal is to form tables
that promote structural and data independence. Given that many table structures will provide the data
required by the organisation’s ER diagrams, normalisation maximises the efficiency of the structure by
reducing data redundancies, eliminating data anomalies and producing a set of controlled redundancies
to link tables that provide the most flexible system for the organisation.
In this chapter, we will take a table and illustrate both the need for normalisation and the normalis­
ation process. Note that in our illustration we will address a number of forms of normalisation, from first
normal form (1NF) to third normal form (3NF).

4.1 Normalisation and database design

LEARNING OBJECTIVE 4.1 Understand and exercise judgement in applying the process of normalisation
to achieve efficient database designs.
The process of normalisation has three outcomes and three actions or steps to achieve those outcomes.
1. First normal form
Outcome: A table has no repeating groups.1
Action: Select a primary key that uniquely identifies each line in the table.
2. Second normal form
Outcome: A table is in first normal form and has no partial dependencies. A partial dependency is
where the attribute is not wholly dependent on the primary key but on part of it.

CHAPTER 4 Database concepts II 137

 Action: Draw dependency arrows. Remove partial dependencies and make the attributes fully depen-
dent on their primary keys.
3. Third normal form
Outcome: A table is in second normal form and has no transitive dependencies. A transitive depen-
dency is where an attribute is dependent on the primary key but via a non-key attribute.
Action: Remove transitive dependencies by making the non-key attribute (which an attribute is depen-
dent on) a primary key in a new table with the attribute. Also leave the non-key attribute as a foreign
key in the existing table so the attribute is dependent on the primary key but via a non-key attribute.
To illustrate these steps and the benefits of normalisation, figure 4.1 has been created to represent the
worst way of recording data. That is, entities and their attributes have been combined without regard for
relationships.
Figure 4.1 is an example of a table that was constructed by a consulting organisation to track its
client projects. The consulting organisation’s employees are attached to one or more client projects, their
charge-out rate, the number of hours they have spent on each of the projects and their phone number.
The organisation’s objective is to be able to cost each client project for billing purposes.
Although it may be possible to calculate the charges associated with each project, extracting infor-
mation from the table is difficult. For example, calculating the charge for each project is a matter
of inserting another column and multiplying Job_chg_hr by Proj_hrs. What if you want to work out
the billings of each of the organisation’s employees (e.g. Michael Burford, Brett Micawber and Phil
Musick)? What if you want to reassign an employee to a different project but retain the hours that the
person has already billed, even after the reassignment (e.g. Michael Burford to Project 3)? What if you
want to change the contact details for an employee (e.g. Michael Burford)? The lack of flexibility in this
table makes it difficult to answer any of these questions because the table was designed primarily with
one question in mind. That is, how long each employee has worked on a project. The difficulties with
this table are similar to those that plagued older file systems, namely, data management issues, structural
and data dependence, and data redundancies.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $120 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678

2 Parade 108 David Smith EE $170 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $120 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $170 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.1 A table used by a consulting organisation to track client projects (this is an example of a poor data
structure as it suffers from all the data anomalies discussed in chapter 3: modification, deletion and
insertion anomalies)

More formally, the redundancies can be described as follows.

•• There are repeating groups in the table. That is, when an employee is assigned to a project, there
is unnecessary repetition. The repeating groups are Proj_name, Proj_num, Emp_num, Emp_name,
Job_code and Emp_phone. This redundancy causes addition, update and deletion anomalies as
described in the following three points.

138 PART 2 Systems characteristics and considerations

•• There are addition anomalies. When you want to add a new employee’s details, their Emp_num,
Emp_name, Job_code and Emp_phone need to be entered. You cannot add these details without
having an employee assigned to a project; therefore, you must have a Proj_name and Proj_num before
you can enter the employee into the table.
•• There are update anomalies. For example, modifying Emp_name requires many alterations. If Michael
Burford wanted to change his name to Michael Burford Majors, this would require alterations to all
the projects that Michael has worked on. Aside from the unproductive consequences of repetition,
there are increased chances of errors.
•• There are deletion anomalies. For example, if Emp_num 101 decides to resign from the consulting
organisation, vital data are lost. This is because Emp_num 101 has worked on Job_code EE, and
deleting the employee from the table will prevent his hours being charged to the project. This will
understate the consultancy’s total costs and lead to undercharging the client.
•• There are data integrity problems. The table allows for spelling and typographical errors. For example,
Michael Burford may be spelt Michelle Burford on a different row in the table.
These items of data redundancy were described in chapter 3. The process of normalisation can be
applied to the table to eliminate data redundancies, as shown in the following section.

Database tables and normalisation

Normalisation involves several objectives, as follows, which together produce a set of related database
tables.
1. Reduce or eliminate repeating groups.
2. Reduce or eliminate data anomalies.
3. Reduce or eliminate data redundancies.
4. Form or organise entities and tables that have structural and data independence.
The normalisation process to achieve these objectives is about defining and reorganising the data
so that each entity (table) contains only the attributes of that entity. For example, the employee table
would contain only details of the employees, and not the details of the projects the employees work on.
Different forms of normalisation can be applied to data. Lower normal forms reduce repeating groups,
data anomalies and data redundancies, while higher normal forms eliminate these groups, anomalies and
redundancies. It should be noted that the highest form of normalisation is not always the best table struc-
ture. Sometimes controlled redundancies via lower forms of normalisation allow for more convenient
and quicker structuring, manipulating or reporting.
The first three normal forms will be explained and applied to the table in figure 4.1. The normal forms
beyond these three will be mentioned briefly. The essence of normalisation is to split the data into sev-
eral tables, which are connected to one another based on the data within them. This saves space; mini-
mises duplication, anomalies and redundancies; protects the data to ensure consistency; and provides
faster transactions because there are fewer data items. For example, an employee’s details are recorded
only once in a database, not in each row of each project they work on. Before illustrating the normalis­
ation process, some definitions need to be recapped.

Definitions
As discussed in chapter 3, a relational database is a collection of carefully defined tables. A table is a
collection of columns or attributes or fields that describe an entity (or something you wish to record
data about in a database). Individual objects are stored as rows or records within the table. The table in
figure 4.1 could represent the entity ‘client projects’ for a consulting company. An important aspect of
the relational database is that the tables must be carefully defined to provide flexibility with minimum
problems. A list of synonyms is included in table 4.1 to remind you of the differing terms used inter-
changeably in database discussions.

CHAPTER 4 Database concepts II 139

 TABLE 4.1 Synonyms used in database discussions

Name Synonym
Table Entity, entity occurrence
Row Record, tuple
Attribute Field, column

Every table must have a primary key, which is an attribute (or column) that uniquely identifies a
particular object (or row) in the table. Also remember that it is better that primary keys are numeric
because they are likely to be unique, short and unchanging, whereas a project name, for example, can be
duplicated. The uniqueness of the number relies on the organisation assigning a unique number to each
project — it could do the same with the name, but it could become difficult over time to come up with
different names. However, alphanumeric combinations — letters in combination with numbers, such as
passport numbers — have many more possible combinations and are therefore appropriate primary keys.
The relationship between the primary key and the rest of the data will be one-to-one; that is, each entry
for a primary key points to exactly one project row. Therefore, the most important issue with a primary
key is that it is unique and can never point to more than one object (or row) in a table.
In many cases a table will use more than one column as part of the primary key. These are called
composite keys. In such cases, one primary key is composed of multiple attributes; a sufficient number
of attributes to uniquely identify each line in the table.

First normal form

Figure 4.1 will be used as the starting point to illustrate the first normal form of normalisation. This table
shows the projects that employees work on. With no primary keys chosen, figure 4.1 is in zero normal
form (0NF). From zero normal form we need to move to first normal form. The first normal form (1NF)
outcome states that we need the table to have no repeating items. That is, for each cell in a table (the
intersection of one row and one column), there can only be one value. This value should not be able to
be decomposed into smaller pieces. Therefore, to achieve no repeating groups we need to choose a pri-
mary key that uniquely identifies each line in the table.
Take a look at figure 4.1. If we consider using a project number (which relates to a project name) as the
primary key, we can see that project number 1 will not uniquely identify one line in the table. Rather, it will
identify three lines. So it is not a satisfactory primary key. If we consider using an employee number as a pri-
mary key, for employee number 101 we will have two rows. However, the primary key of project number and
employee number combined is sufficient, as with each project number, employee number combination only
one line on the table is returned. For example, project number 1, employee number 101 returns only one line;
project number 2, employee number 101 returns only one different line. In summary, this table should have
two attributes as a primary key: Proj_num and Emp_num, as the table is designed to show which employees
are engaged on each project. Each employee (Emp_num) can be engaged on many projects (Proj_num).
For instance, Emp_num 101 appears on project numbers 1 and 2. Because each employee can appear on
many different projects, Proj_num must be part of the primary key. Similarly, each project can engage many
employees (e.g. Proj_num 1 has three employees). Since each project can have many employees, Emp_num
must also be part of the primary key. Whenever there is an M:N (many-to-many) relationship, a composite
key is required. The combination of Proj_num and Emp_num as primary key is known as a composite key.
As discussed in chapter 3, a composite key can also be called a concatenated key as the composite key is
comprised of two or more attributes together. (The word ‘concatenate’ means to put together.)
Primary and composite keys must be properly defined for the normalisation process. The choice of
primary key depends on the 1:M and M:N relationships within the organisation. Figure 4.2 shows the
table from figure 4.1 in first normal form (1NF). Figure 4.2 differs from figure 4.1 by the underlining of
Proj_num and Emp_num, the primary key.

140 PART 2 Systems characteristics and considerations

 Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $120 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678

2 Parade 108 David Smith EE $170 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $120 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $170 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.2 A table used by a consulting organisation to track client projects in first normal form (1NF) (this is still a
poor data structure)

We could also display the table, as in figure 4.3 below, showing only the attributes and the primary
key (i.e. the table header row), but excluding the data. The data is useful in that you can see how attri-
butes within the table are related. The primary key is underlined as previously discussed. The second
part of the figure shows a different format.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

OR

First normal form (1NF)

Proj_num, Proj_name, Emp_num, Emp_name, Job_code, Job_chg_hr, Proj_hrs, Emp_phone

FIGURE 4.3 A table used by a consulting organisation to track client projects in first normal form (1NF)

Second normal form

A table is in second normal form (2NF) if it is in 1NF and does not contain any partial dependencies.
To convert figure 4.2 to 2NF we need to remove the partial dependencies. To do this we need to first
determine the dependencies. Figure 4.4 shows the table from figure 4.2 with the first dependency arrow
drawn on it. The process of identifying dependencies looks at each non-key attribute and what it is
dependent on. Since Proj_num and Emp_num are both a part of the primary key they are not considered
when we are looking at dependency on the primary key (as they are the primary key). Therefore, the first
attribute we consider is Proj_name. Proj_name is the project name and we need to consider what this is
dependent on. For example, if I had the Proj_num, could you give me the project name? The answer is
yes: Proj_num 1 would give us Proj_name Oceania; Proj_num 2 would give us Proj_name Parade and
so on. Therefore, the project name is dependent on the project number, as one project number gives us
one project name. This is shown in figure 4.4 with the arrow pointing from the Proj_name column to the
part of the primary key it is dependent on: Proj_num. So, Proj_name is a partial dependency: it is only
dependent on Proj_num, which is part of the primary key. (Remember, the primary key in this case is a
composite key consisting of both Proj_num and Emp_num.) We will refer to figure 4.4 as Example A.
Example A will relate to the data from figure 4.2. Later in the discussion, we will change the data and
illustrate the normalisation process for examples B, C and D. This will enable us to understand how dif-
ferent data can result in different database structures.

CHAPTER 4 Database concepts II 141

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $120 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678

2 Parade 108 David Smith EE $170 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $120 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $170 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.4 Example A — table used by a consulting organisation to track client projects in first normal form (1NF) with
first dependency arrow

Continuing the process, we can see that Emp_name is dependent on Emp_num: one Emp_num can
identify one employee name. For example, Emp_num 110 gives us the Emp_name Phil Musick. Next
is the attribute Job_code, which is dependent on the employee number. That is, each Emp_num has
only one Job_code. For example, Emp_num 101 returns Job_code EE. Next, Job_chg_hr depends on
Job_code: all Job_code = EE are charged out at Job_chg_hr = $170. The next attribute is Proj_hrs, which
depends on the employee and the time they have spent on the project, which depends on Proj_num and
Emp_num. So, Proj_hours is actually dependent on the whole of the primary key. Lastly, the attribute
Emp_phone is dependent on Emp_num, a part of the primary key. Figure 4.5 shows all of the depen-
dencies discussed above.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $120 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678

2 Parade 108 David Smith EE $170 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $120 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $170 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.5 Example A — table used by a consulting organisation to track client projects in first normal form (1NF)
with dependency arrows

142 PART 2 Systems characteristics and considerations

 To convert figure 4.5 to second normal form (2NF), we need to remove the partial dependencies. To
do this we list the primary key attributes severally and together as the primary key. We do not worry
about whether the keys will have any attributes; they are required to join the tables together so cannot be
eliminated. Listing the primary keys severally and together gives us three tables as shown in figure 4.6.

1. Project table:
Proj_num

2. Employee table:
Emp_num

3. Charge table:
Proj_num, Emp_num

FIGURE 4.6 Primary keys listed for consulting organisation

Each key will define a new table. The final step in 2NF is to link the dependent attributes to each
of the keys as they are defined in the table. The example in the original table in figure 4.2 will now be
divided into three tables: project, employee and charge. This is shown in figure 4.7.

1. Project table:
Proj_num, Proj_name

2. Employee table:
Emp_num, Emp_name, Emp_phone, Job_code, Job_chg_hr

3. Charge table:
Proj_num, Emp_num, Proj_hrs

FIGURE 4.7 Converting to second normal form (2NF)

Notice from the bottom of the table that finding the project charge is simply a matter of constructing
a relevant composite entity with composite keys that include the Proj_hrs attribute of each Emp_num.
Therefore, project name (Proj_name) is now an attribute in the project table as it is dependent on project
number. Employee name (Emp_name) and employee telephone number (Emp_phone) are now attributes
of the employee table. As mentioned above, project hours (Proj_hrs), which relates to the amount of time
the employee spends on a project, becomes the attribute of the table with the composite primary key of
Proj_num, Emp_num. Finally, the job code (Job_code) is dependent on the employee number. Therefore,
job code is shown as an attribute of employee number. The job charge hour (Job_chg_hr) in this case is
dependent on the job code (Job_code) so we put it behind job code (Job_code) in the employee table.
Converting to 2NF adds further manipulation flexibility to the structure by allowing a project to
involve a group of employees and their recorded hours. The second normal form solves several basic
problems. It reduces duplication because there is no need to enter the employee data every time a new
project is initiated. This also saves storage space because employee details no longer need to be allo-
cated to every project. In second normal form, partial dependencies have now been removed. As the
project name is now dependent on the project number primary key in the project table, project name is
now fully dependent on its primary key. It is no longer partially dependent. When project name was in
first normal form it had partial dependency, as it was dependent on part of a composite primary key
(Proj_num, Emp_num). In figure 4.7, only Proj_num is needed to determine Proj_name. Similarly, in
the employee table, only Emp_num is needed to find Emp_name, Job_code and Job_chg_hr. The charge
table and both Proj_num and Emp_num are needed to see which employee numbers (Emp_num) are
engaged on which projects (Proj_num).

CHAPTER 4 Database concepts II 143

Third normal form
A table is said to be in third normal form (3NF) if it is in 2NF and it contains no transitive dependencies.
Figure 4.8 contains the original dependency from job charge hour to job code from figure 4.5. A transi-
tive dependency occurs where one attribute is dependent on another, but neither is part of the primary
key. Therefore, an attribute is dependent on the primary key but via a non-key attribute. These depen-
dencies can contain further anomalies. In figure 4.8, Job_chg_hr is dependent on Job_code and Job_code
is dependent on Emp_num. Therefore, we can see there is a transitive dependency: Job_chg_hr is depen-
dent on Emp_num but via a non-key attribute, Job_code. To transform it into third normal form we need
to remove the transitive dependency.

1. Project table:
Proj_num, Proj_name

2. Employee table:
Emp_num, Emp_name, Emp_phone, Job_code, Job_chg_hr

3. Charge table:
Proj_num, Emp_num, Proj_hrs

FIGURE 4.8 Example A — second normal form (2NF) with dependency arrows

Figure 4.9 shows the tables in third normal form. The project table and charge table from
figure 4.8 have remained the same. The employee table, however, has been changed to remove the transi-
tive dependency.
In particular, Job_code has now become a foreign key in the employee table. a foreign key requires
a primary key elsewhere in the design. Job_code is also a primary key in its own table with an attribute
Job_chg_hr. Job_chg_hr is completely dependent on its primary key, Job_code. Remember that primary
keys are underlined with a hard line. Foreign keys are underlined with a dashed line.

1. Project table:
Proj_num, Proj_name

2. Charge table:
Proj_num, Emp_num, Proj_hrs

3. Employee table:
Emp_num, Emp_name, Emp_phone; Job code

4. Job code table:

Job_code, Job_chg_hr

FIGURE 4.9 Example A — converting to third normal form (3NF) (this is finally a good data structure)

By creating a fourth table, job code, and assigning Job_code as a primary key, we have made a fully
flexible database that can capture almost all of the business structures and rules of the organisation, as
well as answer almost any question that can be asked of the data.
Not only can we have many projects and employees, we can update the charge code for any job code
in one place, and we can record the time spent by employees on each of the projects they work on. Note
that the charge table will always have a composite key signifying the M:N relationship among projects
and employees. If the business wanted to create a new charge-out rate, it would simply create a new
Job_code, enter the new Job_chg_hr, and apply it to the project and employee in the project charge table.

144 PART 2 Systems characteristics and considerations

Changes to employee phone numbers can be made in one location on the employee table; project names
can also be changed in one location on the project table.
What is more, finding out which projects each employee is working on and how many hours they
spend on each is simply a matter of making small changes to the database structure. For example, a table
could be constructed to show each employee’s total billings.
The normalised structure removes update, deletion and modification anomalies. Further, the normal-
ised structure, as a bottom-up approach, can be used to generate an ER diagram. This is illustrated in the
next section and is a similar process to the top-down approach outlined in chapter 3.

Relating the normalised tables — example A

Converting from a normalised structure to an ER diagram is done using the following process. The
structure in figure 4.9 shows a project table with Proj_num and Proj_name, and a charge table with
Proj_num, Emp_num and Proj_hrs. The relationship between the project table and the charge table is
that Proj_num in the project table can relate to many occurrences of Proj_num, Emp_num in the charge
table. However, one occurrence in the charge table, Proj_num, Emp_num, relates to one line in the pro-
ject table. Therefore, the relationship between the project table and the charge table is a one-to-many
relationship (1:N). As discussed in chapter 3, the tables are not physically connected; instead, the con-
nections exist through the matching of data stored in each table.
Likewise, the employee table from figure 4.9 contains Emp_num, Emp_name, Emp_phone and
Job_code, and the charge table contains Proj_num, Emp_num and Proj_hrs. The relationship between
the employee table and the charge table is that Emp_num in the employee table can relate to many
occurrences of Proj_num, Emp_num in the charge table. However, one occurrence in the charge table,
Proj_num, Emp_num, relates to one line in the employee table. Therefore, the relationship between the
employee table and the charge table is one-to-many.
The job code table contains Job_code and Job_chg_hr, which can relate to many occurrences of
Job_code in the employee table. However, one Job_code in the employee table relates to only one
Job_code in the job code table. Therefore, this relationship is also one-to-many.
The ER diagram for figure 4.9 is shown in figure 4.10.

Project table: 1 N Charge table:

Proj_num, Proj_name Proj_num, Emp_num, Proj_hrs

1
Employee table:
Emp_num, Emp_name, Emp_phone, Job_code

1 Job code table:

Job_code, Job_chg_hr

FIGURE 4.10 Example A — ER diagram used by a consulting organisation to track client projects in third
normal form (3NF)

CHAPTER 4 Database concepts II 145

 In short, normalisation of the consulting organisation’s table involved organising a number of tables
that reflect each entity, with each table containing only the dependent attributes of those entities.
The process has reduced, and in some cases eliminated, the data redundancy problems of the original
table (figure 4.1). Further, it has introduced a level of flexibility to meet the information needs of the
organisation that were not available in the original table structure. These design principles are critical for
an efficient and fast-processing database.

Beyond third normal form

There are normalisation processes beyond 3NF. A special type of third normal form, Boyce–Codd
normal form (BCNF), fourth normal form (4NF) and fifth normal form (5NF) are often not performed
because the process usually requires artificial assumptions that rarely hold in the business environment.
These assumptions may not be true all of the time and conducting this further normalisation, ironically,
can reduce the flexibility that the first three normal forms are intended to achieve. As a result, expla-
nation of the normalisation process beyond 3NF is omitted from this book.

Further examples of normalisation

In figure 4.9 for Example A, we saw that the semantics (underlying logic) of the operation of the organisation
is that each employee can have only one job code, and one job code relates to one charge-out rate. To illus-
trate a change of semantics, suppose you were asked to design a database where each employee has different
roles in the business, each of which is linked to a different charge-out rate. The current database design does
not allow this. One change will be implemented at a time to illustrate the effect on how the business works.
First, we will look at the situation where many employees have the same job code at different charge-out
rates. We will refer to this situation as Example B. Figure 4.11 shows this, highlighting employee numbers
101, 108 and 123, which all have job code EE with a charge-out rate of $170, $150 and $70, respectively.
Since no primary keys have been chosen, figure 4.11 is in 0NF.
As discussed, the process of normalisation has three steps.
1. First normal form: select a primary key that uniquely identifies each line in the table.
2. Second normal form: first normal form and remove partial dependencies.
3. Third normal form: second normal form and remove transitive dependencies.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678
1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789
1 Oceania 110 Phil Musick CT $130 14.3 03  4321  0987
2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678
2 Parade 108 David Smith EE $150 17.5 03  3456  7890
3 PuCHRISamu 110 Phil Musick CT $130 11.6 03  4321  0987
3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789
3 PuCHRISamu 123 Michael Clovely EE $ 70 19.1 03  4567  1234
3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.11 Example B — table used by a consulting organisation to track client projects in 0 normal form (0NF) (this
is not a good data structure as it contains the data anomalies discussed in chapter 3)

First normal form

In selecting a primary key, we consider the minimum number of attributes needed to uniquely identify
one record in the table. Proj_num and Emp_num are sufficient as a composite primary key to uniquely
identify each line. The choice of primary key has not changed from the original case. The first normal
form is shown in figure 4.12, with the primary key of Proj_num and Emp_num underlined.

146 PART 2 Systems characteristics and considerations

 Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $130 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678

2 Parade 108 David Smith EE $150 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $130 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $70 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.12 Example B — table used by a consulting organisation to track client projects in first normal form (1NF)

Second normal form

To convert the table to second normal form we need to remove the partial dependencies. To do this
we first identify the dependencies, as shown in figure 4.13. Note the differences from the depen-
dencies illustrated in figure 4.5, our original case. In particular, note the difference in the job charge
hour. In figure 4.5, this was dependent on the job code as all job code EE were charged out at
the same rate, $170. In this case, Job_chg_hr is $170 for Emp_num 101 on Job_code EE; whereas,
Job_chg_hr is $150 for Emp_num 108 on Job_code EE. The job charge hour now is not dependent
on the job code but on the level of expertise of the individual employee, so Job_chg_hr is now depen-
dent on Emp_num.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $130 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $170 19.8 03  1234  5678

2 Parade 108 David Smith EE $150 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $130 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $ 70 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.13 Example B — table used by a consulting organisation to track client projects in first normal form (1NF)
with dependency arrows marked

CHAPTER 4 Database concepts II 147

 We convert this table into second normal form in figure 4.14 by writing down the primary key for
each table with each attribute that is part of the primary key severally and together. Then we write down
the attributes that are wholly dependent on part of the primary key behind the key they are dependent on.
These attributes are then fully dependent on the composite primary key.

1. Project table:
Proj_num, Proj_name

2. Charge table:
Proj_num, Emp_num, Proj_hrs

3. Employee table:
Emp_num, Emp_name, Emp_phone, Job_code, Job_chg_hr

FIGURE 4.14 Example B — converting to second normal form (2NF)

Third normal form

Given there are no transitive dependencies in this case, second normal form is third normal. Figure 4.15
shows the ER diagram for the situation in Example B.

Project table: 1 N Charge table:

Proj_num, Proj_name Proj_num, Emp_num, Proj_hrs

1
Employee table:
Emp_num, Emp_name, Emp_phone, Job_code, Job_chg_hr

FIGURE 4.15 Example B — ER diagram used by a consulting organisation to track client projects in third
normal form (3NF)

Relating the normalised tables — examples B and C

Converting from a normalised structure to an ER diagram is done using the following process.
Figure 4.14 shows a project table with Proj_num and Proj_name and a charge table with Proj_num,
Emp_num and Proj_hrs. The relationship between the project table and the charge table is that
Proj_num in the project table can relate to many occurrences of Proj_num, Emp_num in the charge table.
However, one occurrence in the charge table, Proj_num, Emp_num, relates to one line in the project
table. Therefore, the relationship between the project table and charge table is one-to-many. Similarly
for the employee table containing Emp_num, Emp_name, Emp_phone, Job_code and Job_chg_hr,
a line in the charge table containing Emp_num and Proj_num relates to one line in the employee
table, as one charge-out rate relates to one Emp_num. However, an employee in the employee table
can have multiple project–employee assignments. Therefore, there is also a one-to-many relationship

148 PART 2 Systems characteristics and considerations

between the employee table and the charge table. This is shown graphically in the ER diagram for the
business in figure 4.15. Compare this to figure 4.10, which displayed the business logic of the orig-
inal example. Notice that the ER diagram for Example A shown in figure 4.10 has four tables, but
Example B in figure 4.15, with a change of semantics (underlying logic) of how the business works,
has three tables.
A future change could be that the charge-out rate depends on the employee and which project they
are working on. The data for this new example (Example C) is shown in figure 4.16. Depending on
whether Emp_num 101 is working on Proj_num 1 or 2, they would be charged out at $170 or $52,
respectively.
As outlined above, the process of normalisation has three steps that need to be performed to move
from first normal form to third normal form.
1. First normal form: select a primary key that uniquely identifies each line in the table.
2. Second normal form: first normal form and remove partial dependencies.
3. Third normal form: second normal form and remove transitive dependencies.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $130 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $ 52 19.8 03  1234  5678

2 Parade 108 David Smith EE $150 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $130 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $ 70 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.16 Example C — table used by a consulting organisation to track client projects in 0 normal form (0NF) (this
is not a good data structure as it contains the data anomalies discussed in chapter 3)

First normal form

In first normal form we need to identify the primary key that uniquely identifies each line of the table. As
above, Proj_num and Emp_num are sufficient to do this so we have a primary composite key consisting
of Proj_num and Emp_num. This is shown in figure 4.17.

Second normal form

In removing the partial dependencies, we examine the table and look at what each non-key attribute is
dependent on. Figure 4.17 shows the dependencies, which are the same as the prior cases except for
Job_chg_hr. In this case, Job_chg_hr depends on Emp_num and Proj_num. We can see in the table that
Emp_num 101 with Job_code = EE is charged out at $170 and $52, depending on which project he is
working on. Therefore, Job_chg_hr now becomes an attribute of the Proj_num and Emp_num table as
shown in second normal form in figure 4.18.

CHAPTER 4 Database concepts II 149

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford EE $170 13.3 03  1234  5678

1 Oceania 105 Brett Micawber CT $120 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $130 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $ 52 19.8 03  1234  5678

2 Parade 108 David Smith EE $150 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $130 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $ 70 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.17 Example C — table used by a consulting organisation to track client projects in first normal form (1NF)
with dependency arrows

1. Project table:
Proj_num, Proj_name

2. Charge table:
Proj_num, Emp_num, Proj_hrs, Job_chg_hr

3. Employee table:
Emp_num, Emp_name, Emp_phone, Job_code

FIGURE 4.18 Example C — converting to second normal form (2NF)

Third normal form

Second normal form is also third normal form as we have no transitive dependencies. Everything is
dependent on the primary key. See figure 4.18.

Relating the normalised tables — example D

The linking for the normalised tables occurs in the same way as discussed above. There is a one-to-
many relationship between the project table and the charge table. Proj_num from the project table can
occur in multiple occurrences in the charge table, but any row in which Proj_num, Emp_num occurs in
the charge table relates to only one line in the project table. This is the same with the employee table.
There is therefore a one-to-many relationship between the employee table and the charge table. This is
illustrated in figure 4.19.

150 PART 2 Systems characteristics and considerations

 Project table: 1 N Charge table:
Proj_num, Proj_name Proj_num, Emp_num, Proj_hrs, Job_chg_hr

1
Employee table:
Emp_num, Emp_name, Emp_phone, Job_code

FIGURE 4.19 Example C — ER diagram used by a consulting organisation to track client projects in third
normal form (3NF)

Lastly, what about the semantics when an employee can have multiple job codes? In practice, an
employee may be able to perform more than one skill. For example, EE could stand for electrical
engineer and CT for structural engineer. As another example, an individual may be able to perform
more than one type of job, for instance, accountant and information technology expert. The base table
has been changed (in bold) to reflect these semantics in figure 4.20. This is Example D. Emp_num 101
can charge out as Job_code CT or EE, and even work as both a CT and an EE on the same project
(Proj_num = 1).

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford CT $120 13.3 03  1234  5678

1 Oceania 101 Michael Burford EE $ 52 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $120 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $ 52 19.8 03  1234  5678

2 Parade 108 David Smith EE $ 52 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $120 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $ 52 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.20 Example D — table used by a consulting organisation to track client projects in 0 normal form (0NF) (this
is not a good data structure as it contains data anomalies as discussed in chapter 3)

First normal form

To convert the table into first normal form we need to choose the primary key that will uniquely
identify each line in the table. This time the primary key is different from the previous examples: we
need Proj_num, Emp_num and Job_code to identify a unique line, as there may be one employee
(e.g. Emp_num = 101) working on one project (e.g. Proj_num = 1) but in multiple capacities
(e.g. Job_code = CT and Job_code = EE).

CHAPTER 4 Database concepts II 151

 Second normal form
To convert the table to second normal form we need to remove the partial dependencies. The dependency
arrows are shown in figure 4.21.

Proj_num Proj_name Emp_num Emp_name Job_code Job_chg_hr Proj_hrs Emp_phone

1 Oceania 101 Michael Burford CT $120 13.3 03  1234  5678

1 Oceania 101 Michael Burford EE $ 52 16.2 03  2345  6789

1 Oceania 110 Phil Musick CT $120 14.3 03  4321  0987

2 Parade 101 Michael Burford EE $ 52 19.8 03  1234  5678

2 Parade 108 David Smith EE $ 52 17.5 03  3456  7890

3 PuCHRISamu 110 Phil Musick CT $120 11.6 03  4321  0987

3 PuCHRISamu 105 Brett Micawber CT $120 23.4 03  2345  6789

3 PuCHRISamu 123 Michael Clovely EE $ 52 19.1 03  4567  1234

3 PuCHRISamu 112 Josephine Wyatt BE $170 20.7 03  3456  4567

FIGURE 4.21 Example D — table used by a consulting organisation to track client projects in first normal form (1NF)

The dependencies shown in figure 4.21 are similar to those shown previously for project name,
employee name, project hours and employee phone. Job_code is now part of the primary key so it is
no longer considered in regard to dependency. Job_chg_hr in this case is dependent on Job_code as all
employees with the same job code are charged out at the same rate.
Figure 4.22 shows the tables in second normal form. Note that the primary key consists of three
attributes written severally and together. Also, Proj_hrs are dependent on the employee number
(Emp_num), the project the employee worked on (Proj_num) and in what capacity the employee
worked (Job_code).

1. Project table:
Proj_num, Proj_name
2. Charge table:
Proj_num, Emp_num, Job_code, Proj_hrs
3. Employee table:
Emp_num, Emp_name, Emp_phone
4. Job code table:
Job_code, Job_chg_hr

FIGURE 4.22 Example D — converting to second normal form (2NF)

Third normal form

Since there are no transitive dependencies, second normal form is third normal form. Also note that
in the tables some primary keys may not have attributes. This is not a concern as the normalisation

152 PART 2 Systems characteristics and considerations

process in an organisation addresses every document, report and table and then reconciles the results.
Normalising a large volume of elements and reconciling them with the primary key will often result in
attributes. Even if a primary key does not have attributes it cannot be deleted as it is needed for linking
between tables.
Figure 4.23 shows the ER diagram for Example D. Linking the normalised tables is done in the same
way as for the previous examples.

Project table: 1 N Charge table:

Proj_num, Proj_name Proj_num, Emp_num, Job_code, Proj_hrs

N N

1
Employee table:
Emp_num, Emp_name, Emp_phone

1
Job code table:
Job_code, Job_chg_hr

FIGURE 4.23 Example D — ER diagram used by a consulting organisation to track client projects in
third normal form (3NF)

4.2 Different ways a business works = different

data structures
LEARNING OBJECTIVE 4.2 Critically understand the different ways a business works and how this
reflects in different data structures.
Figure 4.24 shows the ER diagrams from the above examples following the normalisation process.
Remember, the examples used different underlying logic about how the organisation works, but the
same attributes, which resulted in different database structures. Compare the diagrams, noting the
number of tables and how Job_code and Job_chg_hr have been treated. In Example A, an employee
had one job code and was charged out according to that job code. In Example B, different employees
could be charged out at different rates, even employees with the same job code. In Example C, the job
charge-out rate depended on the employee and the project they were working on. Example D allowed
an employee to have multiple job codes and work in multiple capacities on the same project. Changing
the semantics (underlying logic of the data) again would result in further differences in the database
structure.

CHAPTER 4 Database concepts II 153

 ER Diagram — Example A
Project table: 1 N Charge table:
Proj_num, Proj_name Proj_num, Emp_num, Proj_hrs

1
Job charge hour depends
Employee table:
on job code. A person is
Emp_num, Emp_name, Emp_phone, Job_code charged out according to what
job code they have. Therefore,
job_chg_hr is with
N job code.

1 Job code table:

Job_code, Job_chg_hr

ER Diagram — Example B
Project table: 1 N Charge table:
Proj_num, Proj_name Proj_num, Emp_num, Proj_hrs

1
Employee table:
Emp_num, Emp_name, Emp_phone, Job_code, Job_chg_hr Job charge hour depends
on how good the employee is.
Different employees are charged
out at different rates. Therefore,
job_chg_hr is in employee
table.

ER Diagram — Example C
Project table: 1 N Charge table:
Proj_num, Proj_name Proj_num, Emp_num, Proj_hrs, Job_chg_hr

1 Different employees are

Employee table: charged out depending on
how they work on each project. So
Emp_num, Emp_name, Emp_phone, Job_code
their charge-out rate depends on which
employee and which project. Therefore,
the job_chg_hr ends up in the
charge table.

154 PART 2 Systems characteristics and considerations

 ER Diagram — Example D
Project table: 1 N Charge table:
Proj_num, Proj_name Proj_num, Emp_num, Job_code, Proj_hrs

N N

An employee can have

1
multiple job codes depending on
Employee table: which project they work on. Once the
Emp_num, Emp_name, Emp_phone job code for the employee is ascertained,
that rate is contained in the
job_char_hr table.

1
Job code table:
Job_code, Job_chg_hr

FIGURE 4.24 Examples A–D — ER diagrams used by a consulting organisation to track client projects in
third normal form (3NF)

4.3 Enterprise models

LEARNING OBJECTIVE 4.3 Integrate models of a business using entity–relationship modelling and
normalisation to develop an enterprise model.
Combining the ER diagrams and normalisation results for each part of the organisation allows the preparation
of an enterprise model. From the enterprise model, a database for the organisation can be implemented. In
practice, the task of preparing the enterprise model would be completed by technical database designers.
However, the steps in the development of an enterprise model (outlined next) require the input of users and
accountants as to how the business operates. This section of the chapter does not aim to provide the skills to
develop an enterprise model; rather, it overviews the steps in the process and the input required in each step.
Developing the enterprise model requires taking the ER diagrams for different parts of the organ-
isation (e.g. the revenue and expenditure parts of the business) and combining them with any normalis­
ation of the forms and reports within the organisation. This model can then be implemented in a database
that could be called the enterprise database, as it will contain all the entities and relationships in the
organisation. The ER diagrams use the top-down method and normalisation uses bottom-up techniques.
Therefore, top-level strategic views are covered as well as lower operational level input.
The steps for developing an enterprise model start with the steps for developing ER diagrams given
in chapter 3.
Developing an enterprise model
The development of an enterprise model is an iterative process involving six steps.
1. Develop a general narrative of the organisation’s operations, including the business processes, poli-
cies and rules.
2. Construct ER diagrams for each area of operations by identifying the internal and external entities
and the relationships among them from the narrative in step 1. Assign connectivities and cardinalities
based on the narrative.

CHAPTER 4 Database concepts II 155

3. Have the ER diagrams reviewed by the areas of the organisation with ownership of the operations,
policies and processes.
4. Make necessary modifications to incorporate any newly discovered entity–relationship components.
5. Normalise the entities to ensure well-structured data and no data anomalies or data redundancy.
6. Consolidate the ER diagrams.
Repeat this process until the designers and users agree that the enterprise model (which consists of all
the ER diagrams and normalisations combined and reconciled) is complete and represents the relation-
ships and rules that govern the organisation’s entities. Then the organisation can implement the enter-
prise model as a database.
The following example illustrates a simplistic revenue and expenditure cycle in an organisation. For
the purposes of this example, some elements such as stock picking and sales returns have been omitted.
The connectivities and cardinalities have been assumed in this simple example; in a real organisation,
each area would need to identify these on the basis of how the business works. The example shows the
combination of separate revenue and expenditure ER diagrams and normalisations to form an enterprise
model that can be implemented as a database for the organisation.

Developing an enterprise model — steps 1 and 2

Figure 4.25 shows the unnormalised ER diagram for a simple revenue cycle. Figure 4.26 shows the
unnormalised ER diagram for a simple expenditure cycle. (Note that there would be many more entities
(tables) if we were looking at a real organisation’s revenue and expenditure cycles.) Figures 4.25 and
4.26 would be the result of steps 1 and 2.

1 N N M
Customer Places Order Contains Inventory

1 1 1 M

Can have Relates to Contains

N Sales N

Can make
N

Can have

N
N 1
Receipts Relate to Cash

FIGURE 4.25 Unnormalised ER diagram for a simple revenue cycle

156 PART 2 Systems characteristics and considerations

 1 N N M
Supplier Receives Order Contains Inventory

1 1 1 M

Sends Contains Contains

Received
N N
goods

N
Sends

Contains

N 1

1 N
Cash Contains Payments

FIGURE 4.26 Unnormalised ER diagram for a simple expenditure cycle

We can see that figures 4.25 and 4.26 are unnormalised ER diagrams as they contain many-to-many
relationships (M:N). To normalise, we need to resolve these many-to-many relationships. Figure 4.25,
the unnormalised ER diagram for the revenue cycle, contains customer, sales order, inventory, sales,
receipts and cash entities. The unnormalised ER diagram for the expenditure cycle in figure 4.26 con-
tains supplier, purchase order, inventory, received goods, payments and cash entities. The two cycles
have cash and inventory entities in common. When combined into a single ER diagram, the separate
diagrams will join on these common entities.

Developing an enterprise model — steps 3 and 4

In step 3, each area of the organisation would review the ER diagrams in figures 4.25 and 4.26 to ensure
the diagrams reflect the business rules by which the organisation works. As discussed in chapter 3, as
an accountant, your input into this area, in particular in looking at each of the depicted relationships and
ensuring they reflect how the business operates, is critical.
In step 4, modifications to the ER diagrams will be made should any area of the business find discrep-
ancies between how the relationships are represented in the diagrams and how they actually work.

CHAPTER 4 Database concepts II 157

Developing an enterprise model — step 5
Step 5 involves normalising the entities to ensure good structure and no data anomalies or data redun-
dancy. The normalised tables are represented in the ER diagram in figure 4.27 for the revenue cycle
and figure 4.28 for the expenditure cycle. Moving the ER diagrams to the normalised format involves
resolving the many-to-many relationships by creating two one-to-many relationships with a new bridging
entity in the middle.

1 N 1N N1
Customer Places Order Inventory/ Inventory
order

1 1 1 1

Can have Relates to N Inventory/

sales N

N Sales 1

1
Can make
N

Can have

N
N
N 1
Receipts Relate to Cash

FIGURE 4.27 Normalised ER diagram for a simple revenue cycle

In moving to the normalised diagram for the revenue cycle, the first many-to-many relation-
ship in figure 4.25 is the relationship between order and inventory. To move to the normal-
ised model in figure 4.27, place an entity between the order table and the inventory table called
inventory/order. The relationship between order and inventory/order now becomes a one-to-many;
likewise, the relationship between inventory and inventory/order becomes a one-to-many. The
same process is applied to the relationship between inventory and sales, and between sales and
receipts.
Similarly, in figure 4.28, the many-to-many relationships between the entities order and inventory
and inventory and received goods in figure 4.26 have been resolved by inserting the new entities order/
inventory and inventory/receipt.

158 PART 2 Systems characteristics and considerations

 In the normalised ER diagram for the revenue cycle in figure 4.27 you can see the primary and foreign
keys for the entities (tables) within this diagram. For example, for the customer table a primary key of
customer number; for the sales order table a primary key of sales order number, and a foreign key of
customer number. The primary and foreign keys are shown in figure 4.29.

1 N 1N Order/ N1
Supplier Receives Order Inventory
inventory

1 1 1 1

Sends Contains N Inventory/

receipt N

Received
N 1
goods

Sends N

Contains

N 1

1 N
Cash Contains Payments

FIGURE 4.28 Normalised ER diagram for a simple expenditure cycle

Table: Customer

Customer no.

Table: Sales

Sales order no. Customer no.

Table: Inventory

Inventory no.

FIGURE 4.29 Normalised database tables for simple revenue cycle showing primary and foreign keys

(continued)

CHAPTER 4 Database concepts II 159

 FIGURE 4.29 (continued)

Table: Sales order/inventory

Sales order no. Inventory no.

Table: Sales/inventory

Sales invoice no. Inventory no.

Table: Sales

Sales invoice no. Customer no.

Table: Receipts

Cash receipt no. Customer no.

Table: Sales invoice/cash receipts

Sales invoice no. Cash receipt no.

Table: Cash

Account no.

The primary and foreign keys for the expenditure cycle are shown in figure 4.30.
Once the tables are normalised, additional attributes are generated. Take, for example, the sales
order form shown in figure 4.31. When the sales order form is normalised to third normal form, it
will generate the tables as shown in figure 4.32. These can be added to figure 4.29 (the basic tables
for the revenue cycle) to give figure 4.33, which now shows the complete attributes for the revenue
cycle.

Table: Supplier

Supplier no.

Table: Order

Purchase order no. Supplier no.

Table: Inventory

Inventory no.

Table: Sales order/inventory

Purchase order no. Inventory no.

Table: Receives goods — inventory/receipt

Receipt invoice no. Inventory no.

160 PART 2 Systems characteristics and considerations

 Table: Receives goods

Invoice no. Supplier no.

Table: Payments

Cash payment no. Supplier no.

Table: Cash

Account no.

FIGURE 4.30 Normalised database tables for simple expenditure cycle showing primary and foreign keys

Simple company
Level 9, 1 Governor Fitzroy Place
Auckland, 1002

Sales order form No: So-1245 Date: 16 September 2015

TO: M
 s Henriette Videbaek (Customer no: 444545)
46 Mount Wellington Road
Mount Wellington
Ph. 455 3523

Item no. Description Price Quantity Total

FIGURE 4.31 Sales order form

Normalising the sales order form

To normalise the sales order form, the attributes are first written down from the sales order form. The
reason they are transcribed is that not all of them will form tables or attributes in the database. For
example, the name of the company in figure 4.31 — Simple company — and its address details will not
be included in the database. The reason for this is that for an item to be an entity in a database it has to
have multiple occurrences. As there is only one name and address for our company, this does not satisfy
the requirements for forming an entity. Also, in the transcript, items are transcribed more precisely. As
an example, the sales order form simply says Date. However, there are many dates in a business, so we
need to name this accurately and transcribe it into our structure as Sales order date. The same applies to
the customer name. There is a name on the form, but this is not sufficient as there are many names in a
database such as supplier name, customer name, agent name, etc. We need to transcribe the items on a
form so that once the database structure is formed we will always be able to go back and identify what
the item is, such as Customer phone not just Phone.
Total in the sales order line is also removed as this is a derived figure. You can derive it by multiplying
the price of the item by the quantity and therefore it is not stored in the database.

CHAPTER 4 Database concepts II 161

 0NF
Sales order number, Sales order date, Customer number, Customer name, Customer address, Customer city,
Customer phone, Item no., Item description, Item price, Quantity, total line

1NF
Sales order number, Sales order date, Customer number, Customer name, Customer address, Customer city,
Customer phone, Item no., Item description, Item price, Quantity
Sales order number and Item no. are chosen as the attributes that form the primary key that can uniquely identify
each line in the table.

Simple Company
Level 9, 1 Governor Fitzroy Place
Auckland, 1002

Sales order form No: So-1245        Date: 16 September 2015

TO: M
 s Henriette Videbaek (Customer no: 444545)
46 Mount Wellington Road
Mount Wellington
Ph. 455 3523

Item no. Description Price Quantity Total

Write down the key attributes separately and together:

Sales order number
Item no.
Sales order number, Item no.
Then place behind the key the attribute that is wholly dependent on it:

2NF
Sales order number, Sales order date, Customer number, Customer name, Customer address, Customer city, Customer phone

Item no., Item description, Item price

Sales order number, Item no., Quantity
You also might want to put an actual price in the composite entity in order to be able to regenerate the sales
order if prices increase.
In relation to customer number, customer name depends on sales order number transitively through customer
number as well as customer address, customer city and customer phone. These transitive dependencies need to
be removed in third normal form.

3NF
Sales order number, Sales order date, Customer number
Customer number, Customer name, Customer address, Customer city, Customer phone
Item no., Item description, Item price
Sales order number, Item no., Quantity, Actual price.
When combined with the full model, the Item no. is renamed Inventory as it is called Inventory in all the other
models and we should name the same item consistently.

FIGURE 4.32 Sales order form tables and attributes

162 PART 2 Systems characteristics and considerations

Table: Customer

Customer Customer
Customer no. Customer name address Customer city phone

Table: Sales

Sales order no. Sales order date Customer no.

Table: Inventory

Inventory no. Inventory description Inventory price

Table: Sales order/inventory

Inventory actual
Sales order no. Inventory no. Quantity price

FIGURE 4.33 Normalised database tables for simple revenue cycle

Table: Customer

Customer Customer Customer Customer

Customer no. Customer name address city phone credit limit

Table: Sales

Sales order no. Sales order date Customer no.

Table: Inventory

Inventory no. Inventory description Inventory price

Table: Sales order/inventory

Sales order no. Inventory no. Quantity Inventory actual price

Table: Sales/inventory

Inventory
Sales invoice no. Inventory no. actual price Quantity

Table: Sales

Sales invoice no. Sales invoice date Customer no.

FIGURE 4.34 Attributes for the expenditure cycle (continued)

CHAPTER 4 Database concepts II 163

 FIGURE 4.34 (continued)

Table: Receipts

Cash receipt no. Customer no. Total amount Cash receipts date

Table: Sales invoice/cash receipts

Sales invoice no. Cash receipt no. Amount

Table: Cash

Account no. Balance

Table: Supplier

Supplier no. Supplier name Supplier address Supplier phone

Table: Order

Purchase order no. Purchase order date Supplier no.

Table: Inventory

Inventory no. Inventory description Inventory price

Table: Sales order/inventory

Purchase order no. Inventory no. Quantity

Table: Receive goods — inventory/receipt

Receipt invoice no. Inventory no. Quantity

Table: Receive goods

Invoice no. Invoice date Supplier no. Supplier invoice date

Table: Payments

Cash payments no. Supplier no. Total amount Cash payments date

Table: Cash

Account no. Balance

FIGURE 4.35 Normalised database tables for simple expenditure cycle

164 PART 2 Systems characteristics and considerations

Developing an enterprise model — step 6
Notice that the cash and the inventory entities are common between the revenue and expenditure
ER diagrams. Therefore, these tables can be consolidated across the entities. If the cash entity
and the inventory entity had different attributes, they would be combined and normalised. The
tables and attributes for the enterprise model are a combination of the tables and attributes from
figure 4.33 (tables and attributes for the revenue cycle) and figure 4.34 (tables and attributes for
the expenditure cycle), joined via the inventory and cash tables. Since both figures 4.33 and 4.34
have cash and inventory tables, the final model will have only one table for inventory and one for
cash. The enterprise model (which is an ER diagram for the whole of the organisation) is shown in
figure 4.36.

1 N 1N N1 1N Order/ N1 N 1
Customer Places Order Inventory/ Inventory Order Receives Supplier
inventory
order

1 1 1 1 1 1 1 1

Can have Relates to N Inventory/ Inventory/ N Contains Sends

N N receipt
sales

1
N
1 N
Received
N Sales 1
goods

1 N
Can make Sends
N

Invoice/ Contains
receipt

N
1 1
N
N 1 1 N
N Receipts Relate to Cash Contains Payment

FIGURE 4.36 Enterprise model for the organisation

After consolidating the diagrams into a single enterprise model, users and other members of the organ-
isation need to agree that the model represents the relationships in the organisation and that the table
designs in figures 4.33, 4.34 and 4.35 represent all the data that needs to be collected in the database.
Note that the above example includes only a few entities and attributes and minimal interaction
between them. The number would increase for a real-world organisation, particularly if other transaction
cycles such as human resources, payroll, finance, general ledger and goods returns were included.

4.4 The REA Accounting Model

LEARNING OBJECTIVE 4.4 Justify the REA (resources–events–agents) Accounting Model as a template
for modelling accounting systems.
Another way to model data is to use the REA (resources–events–agents) Accounting Model. Database
designers have used the REA Accounting Model as a template for developing database models that can
be used for databases.
The REA Accounting Model was developed by William McCarthy in 19822 and has been since
expanded in a series of papers. McCarthy suggested that an enterprise information system should be
a representation of the actual activities or events that occur in the organisation rather than a particular
view of the data such as a debit or credit or a journal entry. He used the enterprise information system
to show the information system for the whole of the business. (In learning objective 3 earlier we used

CHAPTER 4 Database concepts II 165

the term enterprise model (or enterprise database) instead of enterprise information system to indicate
the system for the whole of the business.) The REA Accounting Model defines common patterns in enti-
ties and activities or events that are found in all organisations. It is based on a thorough understanding
of an organisation’s context, entities, business processes, risks and information needs through systems
mapping and documentation. The REA Accounting Model is beyond the scope of this book. However,
there are books and courses that explain the model and its use in database design in great depth. The
following explanation provides an overview of how the model can be used to develop a database for a
sales business process.
REA models the exchanges in the various processes in an organisation and brings these exchanges
together to form an enterprise system. Consider the simple sales process shown in figure 4.37 where a
sale is made to a customer.

Made
Sale Customer
to

FIGURE 4.37 Sales process

The process can be described as a customer sale of a product. The diagram in figure 4.37 can be
expanded to the ER diagram in figure 4.38 to show the entities that are recorded as a result of the sales
process: customer, cash and product. Tables in the database must be able to capture the interactions
between the customer and the cash, and the cash and the product.

Customers Give Cash

Purchase

Products

FIGURE 4.38 Expanded ER diagram showing entities and exchanges between them

How did we come up with the elements of the ER diagram? How did we know how to define the enti-
ties and the interactions between the entities? The answer is based on understanding and experience of
the business and the relationships within it.
REA database modelling provides a more structured approach to developing a database model and
database structure for a business process such as the sales process. REA is based on the premise that in

166 PART 2 Systems characteristics and considerations

every exchange in a process there is a resource, event and agent involved. A resource is an item that is
anything but an agent. In our sales process example, it could be the product or the cash. Hence, an agent
is the human that is involved in the exchange. In our sales process example, the agent could be the cus-
tomer, cashier or salesperson. The event is the occurrence between the resources and the agents. William
McCarthy proposed that in every exchange, such as the sales process, there are common patterns of
inflows and outflows. He presented the concept of ‘duality’, and concluded that all exchanges could be
represented by the general REA pattern in figure 4.39.

Internal
agent
Increase
Resource
event

Outside
agent

Decrease
Resource
event
Internal
agent

FIGURE 4.39 General REA pattern

Our simple sales process can therefore be translated into the REA pattern shown in figure 4.40.

Sales
person

Product Order

Outflow Customer
Inflow

Customer
Cash
payment
Cashier

FIGURE 4.40 Sales process REA pattern

The resources, events and agents represent the key tables and the relationships that have to exist in a
database in order to capture the details underlying that exchange, as shown in the database structure in
figure 4.41.
In summary, the REA Accounting Model, which involves defining the exchanges and developing the
dualities between resources, events and agents, assists the development of database structures that can be
used to capture the details of a business process.

CHAPTER 4 Database concepts II 167

 Product Sales person

prod_id sales_id

Order

prod_id
sales_id
cust_id

Customer

cust_id

Cash
Payment
cashrecpt_id
payment_id
Cashier
cashrecpt_id
cust_id
cashier_id
cashier_id

FIGURE 4.41 Database structure

REA Accounting Model example

The REA model has not been implemented in an actual accounting system in practice, as it concentrates
on economic events rather than debit/credit transactions. However, REA is used for accounting system
modelling. Resources, events and agents are depicted when an economic event such as a sale occurs.
The resulting model does not contain debits and credits, journals or ledgers, or other items of accounting
convention such as debtors, creditors or capital as accounts with balances in an event-driven model.
The lack of these elements may explain the reluctance of or resistance by accountants to implementing
this model, as it does not reconcile with the debit/credit systems that they would be used to. Further, if
an organisation has an existing legacy system that uses debits and credits, it is not possible to amend it
to add new functionality using the REA model. Still, REA is useful for modelling business events. In
addition, developments are continually being made to the REA model.
The following example illustrates the REA model and how it is different from the relational database
that we have been using up to this point by showing the same transactions using a traditional debit and
credit system (a non-REA model) and an REA model. The transactions are an example of a sale and a
cash receipt.

Transaction 1:
1 March 2015, 10 units of Product A are sold for $10 per unit to Customer B.
Product A cost $5 per unit.

Transaction 2:
10 March 2015, $50 is received from Customer B.

168 PART 2 Systems characteristics and considerations

Traditional relational database accounting system (non-REA model)
Figure 4.42 illustrates the entries under a traditional, non-REA accounting system.

Journal entries

2015 Debit Credit

Mar. 1 Debit — Debtor B 100

Credit — Sales 100

Debit — Cost of Goods Sold 50

Credit — Inventory 50

Mar. 10 Debit — Cash 50

Credit — Debtor B 50

Ledger balances

Debtor B Debit Credit

2015

Opening Balance   0

Mar. 1 Credit Sales 100
10 Cash __ 50
Closing Balance 50

Sales Debit Credit

2015

Opening Balance   0

Mar. 1 Debtors 100

Cost of Goods Debit Credit

2015

Opening Balance   0

Mar. 1 Inventory 50

Inventory Debit Credit

2015

Opening Balance   0

Mar. 1 Cost of Goods Sold 50

Cash Debit Credit

2015

Opening Balance   0

Mar. 10 Debtors 50 _
Closing Balance 50

FIGURE 4.42 Traditional accounting system (non-REA) — journal entries and subsequent ledger
balances

CHAPTER 4 Database concepts II 169

 We can see from the traditional accounting system (the non-REA model) that we have a balance of
$50 in debtors using journals and ledgers.
REA model
Figure 4.43 illustrates the entries under an REA Accounting Model. Attributes have been chosen to illus-
trate the system (more attributes could be used in reality).

Table: Customer

Customer no. Customer name Customer address Customer credit limit

101 Customer B

Table: Invoice

Invoice no. Invoice date Customer no.

1 1 March 2015 101

Table: Sales

Invoice no. Product no. Quantity

1 201 10

Table: Product

Product no. Product description Price Cost

201 Product A 10 5

Table: Cash receipts

Cash receipts no. Date Customer no. Amount

301 10 March 2015 101 50

FIGURE 4.43 REA model tables

4.5 Differences between REA and ER modelling

LEARNING OBJECTIVE 4.5 Critically differentiate the differences between REA and entity–relationship
modelling.
In the REA model, in the absence of a debtors account to work out the debtors balance, look at the
sales table, link it to the price in the product table less what is in the cash receipts table relating to that
customer. Using normal database conventions, primary keys are shown with the attribute underlined
and foreign keys are shown with the attribute having a dashed underline. Therefore, we can see from
the invoice table that customer 101 bought goods on 1 March 2015. The invoice table is linked to the
customer table via the foreign key of Customer no. via the Invoice no., so we can link the invoice table
to the sales table in which we can see customer 101 bought 10 of product 201. We can then link the
Product no. in the sales table to the product table to see that product number 201 is Product A and it sells

170 PART 2 Systems characteristics and considerations

for $10. So, we can calculate a sale of $100 to customer 101. Next, we can see from the cash receipts
table that we have $50 received from customer number 101, which is Customer B. This is done via the
link in the cash receipts table to the foreign key Customer no., which in turn links to the customer table
that has Customer no. as its primary key. If we take the $100 sale from Customer B and take away the
$50 cash receipt from Customer B, we have a balance of $50 owing from Customer B. This is quite a
different process than for the traditional accounting model (non-REA model) where we can easily see
the balance of Customer B (Debtor B).
Despite the reluctance of businesses to use REA to implement accounting systems, one of the REA
model’s greatest advantages is that it can store non-financial data as well as financial data. And it is poss-
ible for organisations to use REA to model their business processes, but then implement the relationships
via a traditional accounting system (i.e. that uses debits and credits). In this way, REA is implemented
as a relational database.

4.6 Database implementation

LEARNING OBJECTIVE 4.6 Communicate and discuss the technologies relating to database
implementation.
Relational databases need to be centralised within the organisation, but still allow organisation-wide
access. Hardware and networks provide the critical platforms to achieve this. Only relatively recently
have computer power, operating systems and data communications reached a level that makes it possible
to operationalise the use, manipulation and storage of relational databases.
This final section of this chapter briefly explains how client–server systems and e-commerce have
affected the design, implementation and management of relational database systems and business infor-
mation systems in general. In particular, this section overviews how client–server systems have provided
opportunities for organisations to use developments in logically designed relational database implemen-
tation models. While logical views of database implementation models such as relational databases have
been used in the discussion up to this point, the next section explains the client–server implementation
model using a physical perspective.

Client–server systems
A client–server system distributes computing functions between two types of independent and auton-
omous processes: servers and clients. A client is any process that requests specific services from a server.
A server is a process that provides requested services for clients. Client and server processes commonly
exist on different computers connected by a network. For example, many workplaces have individual
PCs (clients), which contain the individual email accounts of users. These individual PCs are likely to
be connected through a network to an email server, which receives and sends email into and out of the
organisation.
When client and server processes reside on two or more computers on a network, the server can
provide services for more than one client. A client can also request services from several servers on a
network without regard to the location of the computer on which the server process resides. Figure 4.44
shows three of many possible client–server configurations. Panel A illustrates a single computer as client
and server. A small business using a database may employ such a configuration. The PC processes every
request within itself. In panel B, a server is shown with a number of clients. Small to medium businesses
with a number of employees running a database may require employees to have access at the same time.
The server houses the centralised database, which can be accessed by employees using their client.
Panel C shows a single client with more than one server. This configuration may be used by an organ-
isation that requires servers for specialised functions such as databases, email, applications and so on.
Clients may access each of these servers depending on the functionality that they require in conducting
business. This configuration is normally used in large organisations that have multiple locations.

CHAPTER 4 Database concepts II 171

 Panel A Panel C

Panel B

FIGURE 4.44 Client–server models

The technical details behind client–server systems relate to how far processing is shared, the tiers of
client–servers, and the architecture including components and middleware.
A server or client can be described as fat or thin depending on how far the processing is
shared between the client and the server. A thin client conducts minimal processing and is nor-
mally used in conjunction with a fat server, which conducts most of the processing. Conversely, a
fat client takes on a relatively large processing load and is usually used in combination with a thin
server, which carries a relatively low processing load. Thin clients are frequently implemented for
users that perform basic administration and operational functions in the database such as the bank
teller’s computer in a bank. The fat client is typically given to database managers, administrators or
programmers who need the processing power to make significant changes or maintain a relational
database.
Client–server systems can also be classified as two-tier or three-tier. A client requesting services
directly from a server is known as a two-tier client–server system. Where the client’s request is handled
by intermediate servers (which coordinate the execution of the client requests with other servers), this is
known as a three-tier client–server system.
Client–server architecture is based on three major components: hardware, software and communi-
cations middleware. The hardware is made up of the physical computers and physical servers that
represent the client and the server. Front-end application software is software that is usually loaded
onto the client computers as the means for the user to interact with the server as part of the client
process. Back-end application software is usually loaded onto the server to provide essential back-
ground services to the clients. Communications middleware is the software by which clients and
servers communicate. The communications middleware or communication layer holds different types
of software that aid the transmission of data and control of information between the client and server.
The middleware sits partly on the client and partly on the server and allows the two to communicate
and interact.

172 PART 2 Systems characteristics and considerations

 Figure 4.45 shows how client and server components interact through communications middleware. A
client computer sends the request in SQL through the middleware on its computer, which routes the SQL
request through the network to the middleware sitting in the database server process. The database server
processes the request, validates it and executes it, sending the data back to the client via the middleware
layer.

Receives
Client sends Middleware request,
SQL through sends SQL to validates and
middleware database server executes

SQL SQL SQL

Client Server Database

Client process
middleware middleware server

Data Data Data

FIGURE 4.45 The interaction of client–server components

The ability to allocate processing between clients and servers in a network allows:
•• organisations to centralise information that can be accessed by everyone through client PCs
•• flexibility, adaptability and scalability for the organisation to add and subtract users and capacity to a
growing or changing organisation
•• the above to be accomplished without the costs of purchasing and developing new systems each time.
This discussion on the client–server environment also shows how the system architecture permits
these advantages because the system can:
•• be built on independent hardware and software platforms
•• optimise the distribution of processing activities using the comparative advantages of each of the
platforms
•• use a variety of techniques, methodologies and specialised tools to develop systems that are user-
friendly, cost-effective and communicative across all boundaries.
The implementation of truly flexible relational database systems could only have been brought
about with client–server architecture. This architecture has reduced the development and imple-
mentation costs in constructing a system to capture complex and diverse business activities. This
architecture manifests itself in the myriad enterprise information systems in use today. Small busi-
ness systems such as MYOB and large ERP systems such as SAP and Oracle use these relational
databases as a basis to capture, store and manage data and information for decision making and
reporting.

Databases in e-commerce
The internet has changed the way organisations of all types operate. Buying and selling goods and ser-
vices online between businesses, suppliers and customers has become commonplace, and this interaction
is known as e-commerce.
E-commerce and the internet have also affected database systems. Organisations with relational data-
base systems, for example, are now allowing their staff to access the system externally through the
internet. In addition, the internet is allowing organisations to give their suppliers and customers access
to their internally focused relational database. A wide range of supply chain and customer relationship
management software has been developed that can be linked with database systems, to permit communi-
cation and commerce between organisations. There are also other relational databases with structures
that are specifically constructed for supply chain and customer relationship purposes.

CHAPTER 4 Database concepts II 173

SUMMARY
4.1 Understand and exercise judgement in applying the process of normalisation to
achieve efficient database designs.
Designing a database requires taking the database model and creating tables to represent every internal
and external entity that is important to the business. Once the table structure is defined, normalisation is
used. Normalisation is the process of assigning attributes to entities to eliminate the repetition of groups
and data redundancies in order to form tables that promote structural and data independence. Therefore,
normalisation maximises the efficiency of the structure of data. There are a number of forms of normal-
isation from 1NF to 5NF; however, for financial systems we stop at 3NF.

4.2 Critically understand the different ways a business works and how this reflects in
different data structures.
Different underlying logic in the data will result in different data structures even though the business’s
attributes may be the same as those of another business. Therefore, given the same attributes of two
organisations, one business’s database is unable to be used in the other business.
4.3 Integrate models of a business using entity–relationship modelling and normalisation to
develop an enterprise model.
An enterprise model of a business is the complete model of the business that can be implemented in
an enterprise database. An enterprise model of a business is created by combining the ER diagrams of
different parts of the business along with the normalisation of different forms and reports in the organ-
isation. By combining and reconciling the tables and attributes a model of the whole enterprise can be
created. Consultation with the users in the organisation is required to ensure the enterprise model reflects
how the organisation works.
4.4 Justify the REA (resources–events–agents) Accounting Model as a template for
modelling accounting systems.
The REA (resources–events–agents) Accounting Model is a way of modelling data for databases.
REA is based on the premise that in every exchange in a process there is a resource, event and agent
involved. A resource is an item that is anything but an agent. In our sales process example, it could
be the product or the cash. Hence, an agent is the human that is involved in the exchange. In a sales
process example, the agent could be the customer, cashier or salesperson. The event is the occurrence
between the resources and the agents. It is proposed that in every exchange, such as the sales pro-
cess, there are common patterns of inflows and outflows, and all exchanges can be represented by the
general REA pattern.
4.5 Critically differentiate the differences between REA and entity–relationship modelling.
REA uses events modelling rather than the traditional accounting system, which uses journal entries,
ledgers, and debits and credits. Balances for debtors, creditors, bank and capital need to be calculated
from the events that occur in the business. For example, the debtors balance must be calculated from
the sales to the customer, minus the payments from the customer and any returns. The balance needs
to be calculated because it is not available as it would be in a traditional relational database accounting
system. However, REA has the capability of storing non-financial data, while a traditional relational
database accounting system does not.
4.6 Communicate and discuss the technologies relating to database implementation.
Client–server computing is a physical implementation model that is based on distributing
functions between the two types of independent and autonomous processes: servers and clients. Servers
have special processing functions that provide requests from clients. Clients request services from a
server. This functionality allows organisations to run networks with centralised information in a rela-
tional database that is accessible by everyone through client PCs. It also permits flexibility, adaptability

174 PART 2 Systems characteristics and considerations

and scalability for databases. Employees can configure databases to best suit their output needs, which
improves workflow and hence productivity. This is because the system is built on independent hardware
and software platforms, which can be optimised for distribution of processing activities.

KEY TERMS
Attributes Characteristics of entities.
Back-end application software Software that is usually loaded onto the server to provide essential
background services to clients.
Client A computer that requests services from a server.
Client–server system A computing model that is based on distributing functions between two types of
independent and autonomous processes: servers and clients.
Communications middleware Software that holds different types of software that aid the
transmission of data and control of information between the client and server.
Composite key A combination of more than one attribute to form one primary key. It indicates an
M:N (many-to-many) relationship between the columns.
Controlled redundancies Redundancies that are allowed for the convenience of structuring data, data
manipulation or reporting.
Entities Representations of real-world things or objects that are involved in a process and correspond to a
table in a relational database.
Field A characteristic of a record that contains data that have a specific meaning.
Foreign key An attribute whose values must match the primary key in another table.
Front-end application software Software that is usually loaded onto the client computers as the
means for the users to interact with the server as part of the client process.
Hardware Physical devices including the computer and network.
Many-to-many relationship (M:N) A relationship between two entities in which the cardinality of
both entities in the relationship is many.
Normalisation A set of rules and a process of assigning attributes to entities to eliminate repeating groups and
data redundancies, and to form tables representing entities that promote structural and data independence.
One-to-many relationship (1:N) A relationship between two entities in which the cardinality of one
entity in the relationship is one and the other entity’s cardinality is many.
Partial dependency A dependency based on only part of a composite primary key.
Primary key An attribute (or column) that uniquely identifies a particular object (or row).
Record A connected set of fields that describes a person, place or thing.
Relational database A database that stores data in a number of tables.
Server A computer that has special processing functions that provide requests from clients.
Software Computer programs that are written in programming languages or code that instruct the
operations of a computer.
Table A collection of columns (attributes) and rows (objects) that describe an entity.
Transitive dependency A dependency that occurs when one attribute is dependent on another, but
neither is part of a primary key.

DISCUSSION QUESTIONS
4.1 Describe the process of normalisation for database design. (LO1)
4.2 What is a primary key? (LO1)
4.3 What is a composite primary key? Give an example of how it has arisen. (LO1)
4.4 What is the purpose of normalisation in a database? (LO1)
4.5 Explain what considerations and judgement are needed in choosing a primary key for an
unnormalised table? Give an example. (LO1)

CHAPTER 4 Database concepts II 175

 4.6 Critically explain how normalisation enhances decision making and reporting? (LO1)
4.7 Describe a partial dependency. Give an example. (LO1)
4.8 Describe a transitive dependency. Give an example. (LO1)
4.9 How do normalised structures change depending on different relationships in the data? (LO2)
4.10 Discuss the steps required to construct an enterprise model of a business. (LO3)
4.11 Justify the REA model. (LO4)
4.12 Discuss the differences between an REA model and ER modelling. (LO5)
4.13 Communicate and discuss the implications of client–server computing for
implementing relational databases. (LO6)
4.14 How have e-commerce and the internet affected the accessibility of database
applications? (LO6)

SELF-TEST ACTIVITIES
4.1 A table to be normalised starts at what normal form? (LO1)
(a) 0NF
(b) 1NF
(c) 2NF
(d) 3NF
4.2 Can a table which is in 2NF also be in 3NF? (LO1)
(a) Yes, when there are no partial dependencies.
(b) Yes, when there are no transitive dependencies.
(c) Yes, when there are no functional dependencies.
(d) None of the above.
4.3 A composite primary key can also be called a: (LO1)
(a) concatenated primary key.
(b) foreign key.
(c) primary key.
(d) none of the above.
4.4 A partial dependency is when: (LO1)
(a) an attribute is dependent on the primary key wholly.
(b) an attribute is dependent on the primary key but via a non-key attribute.
(c) an attribute is only dependent on part of the primary key.
(d) none of the above.
4.5 A transitive dependency is when: (LO1)
(a) an attribute is dependent on the primary key wholly.
(b) an attribute is dependent on the primary key but via a non-key attribute.
(c) an attribute is only dependent on part of the primary key.
(d) none of the above.
4.6 Client–server architecture is based on: (LO6)
(a) hardware, software and communications middleware.
(b) mainframes and terminals.
(c) databases, tables and keys.
(d) none of the above.

PROBLEMS
4.1 Happy Feet Shoes is a large retailer of women’s shoes. The organisation runs a file system.
The following is an extract of its sales file. (LO1)

176 PART 2 Systems characteristics and considerations

 Customer_name Customer_address Customer_phone Salesperson Shoe_model Shoe_amount Date

Britney Micawber 2 Apple Street, 03 1234 5678 TLM VZ4717 $29.90 20-Jul-15
Melbourne, VIC

Michelle Burford 6 Organic Street, 03 9876 4321 CBD DF3966 $79.50 30-Jul-15
Melbourne, VIC

Phillipa Musick 8 Grapefruit Street, 03 5678 3456 MTL WE9447 $50.30 4-Aug-15
Melbourne, VIC

Devine Smith 3 Echo Street, 03 2376 1048 JFK XC8187 $45.50 6-Oct-15
Melbourne, VIC

Required
(a) Normalise this table to third normal form. Show all forms.
(b) Discuss any assumptions you have made in normalising the table.
(c) Illustrate your normalisation by providing an entity–relationship (ER) diagram.
4.2 Magnificent Music started in Melbourne and is expanding by setting up stores in every other
capital city in Australia. It will be selling CDs and DVDs of all varieties in every store.
Magnificent Music has decided that it wants a centralised database that can be accessed by every
store in Australia. To operate efficiently and effectively, it requires a client–server system.(LO6)
Required
(a) Explain the importance of client–server computing for database access in each of its stores.
(b) How does the client–server architecture extract the best from the database?
4.3 Part A: Below is a table for a university database.(LO2)

0NF

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

9938214 TA6000 Tax Avoidance 1 JAMES 927 A

9938214 BIS6103 Databases 2 KARIN 947 C

9969173 BIS6103 Databases 2 KARIN 947 A

9969173 BIS6102 Business Process 3 RAEWYN 935 B

Management

9969173 TA7000 Disputes Resolution 4 CHRIS 327 C

1NF

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

9938214 TA6000 Tax Avoidance 1 JAMES 927 A

9938214 BIS6103 Databases 2 KARIN 947 C

9969173 BIS6103 Databases 2 KARIN 947 A

9969173 BIS6102 Business Process 3 RAEWYN 935 B

Management

9969173 TA7000 Disputes Resolution 4 CHRIS 327 C

CHAPTER 4 Database concepts II 177

1NF with dependency arrows

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

9938214 TA6000 Tax Avoidance 1 JAMES 927 A

9938214 BIS6103 Databases 2 KARIN 947 C

9969173 BIS6103 Databases 2 KARIN 947 A

9969173 BIS6102 Business Process 3 RAEWYN 935 B

Management

9969173 TA7000 Disputes Resolution 4 CHRIS 327 C

In first normal form, student number and course number have been chosen as a primary key to
uniquely identify each line in the table.
2NF

Student table:
Student number

Course table:
Course number, Course title, Instructor number, Instructor name, Instructor location

Student course (enrolment table):

Student number, Course number, Grade

Note that the student table has no attributes in this problem. However, as discussed in the chapter,
when forming the enterprise model for the business it is likely that in combining tables the student table
will have attributes such as student name, student phone number and student address. Even though
the student table does not have attributes in this problem, it is important and should not be deleted.
Remember that when the full enterprise model is formed it is likely that this table will have attributes.
There is a dependency arrow from instructor name to instructor number and from instructor
location to instructor number. Therefore, we have a transitive dependency: instructor name is
dependent on the primary key, course number, via the non-key attribute instructor number. The
same situation arises with instructor location. To remove the transitive dependencies we need to
move to third normal form.

3NF

Student table:
Student number

Course table:
Course number, Course title, Instructor number

Instructor table:
Instructor number, Instructor name, Instructor location

Student course (enrolment table):

Student number, Course number, Grade

178 PART 2 Systems characteristics and considerations

 Note that to remove the transitive dependency, instructor number becomes a foreign key in
the course number table (shown by a dashed line underneath the instructor number in the course
table). Then instructor number becomes a primary key in its own table. The attributes, instructor
name and instructor location, are now attributes of the instructor table.

Student number Student number, Course number, Grade Course number, Course title, Instructor number

Instructor number, Instructor name, Instructor location

Required
(a) The table has been normalised to third normal form. Explain the logic underlying the table;
that is, how the university works. Comment on the entity–relationship diagram.
Part B: The university table has been amended as shown in bold below. David is now also an
instructor for databases. This table has again been normalised to third normal form. (LO2)

0NF

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

38214 TA6000 Tax Avoidance 1 JAMES 927 A

38214 BIS6103 Databases 2 KARIN 947 C

69173 BIS6103 Databases 5 DAVID 944 A

69173 BIS6102 Business Process 3 RAEWYN 935 B

Management

69173 TA7000 Disputes Resolution 4 CHRIS 327 C

1NF

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

38214 TA6000 Tax Avoidance 1 JAMES 927 A

38214 BIS6103 Databases 2 KARIN 947 C

69173 BIS6103 Databases 5 DAVID 944 A

69173 BIS6102 Business Process 3 RAEWYN 935 B

Management

69173 TA7000 Disputes Resolution 4 CHRIS 327 C

CHAPTER 4 Database concepts II 179

 Note that a primary key consisting of the attributes student number and course number is a
sufficient composite primary key to identify each line in the table.

1NF with dependency arrows

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

38214 TA6000 Tax Avoidance 1 JAMES 927 A

38214 BIS6103 Databases 2 KARIN 947 C

69173 BIS6103 Databases 5 DAVID 944 A

69173 BIS6102 Business Process 3 RAEWYN 935 B

Management

69173 TA7000 Disputes Resolution 4 CHRIS 327 C

2NF

Student table:
Student number

Course table:
Course number, Course title

Student course (enrolment table):

Student number, Course number, Instructor number, Instructor name, Instructor location, Grade

Note that both instructor name and instructor location are dependent on instructor number.
Therefore, instructor name and instructor location are dependent on the primary key of the
student course (enrolment table) but via the non-key attribute of instructor number. Therefore, the
transitive dependency needs to be removed before the third normal form is achieved.

3NF

Student table:
Student number

Course table:
Course number, Course title

Student course (enrolment table):

Student number, Course number, Instructor number, Grade

Instructor table:
Instructor number, Instructor name, Instructor location

180 PART 2 Systems characteristics and considerations

 Student number Student number, Course number, Grade, Instructor number Course number, Course title

Instructor number, Instructor name, Instructor location

Required
(b) Explain the logic underlying the table; that is, how the university works given the above
change. Comment on the ER diagram.
Part C: The university table below has again been amended as shown in bold. Karin is
now the lecturer for Disputes Resolution. This table has again been normalised to third
normal form. (LO2)

0NF

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

38214 TA6000 Tax Avoidance 1 JAMES 927 A

38214 BIS6103 Databases 2 KARIN 947 C

69173 BIS6103 Databases 5 DAVID 944 A

69173 BIS6102 Business Process 3 RAEWYN 935 B

Management

69173 TA7000 Disputes Resolution 4 CHRIS 327 C

09667 TA7000 Disputes Resolution 2 KARIN 925 C

1NF

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

38214 TA6000 Tax Avoidance 1 JAMES 927 A

38214 BIS6103 Databases 2 KARIN 947 C

69173 BIS6103 Databases 5 DAVID 944 A

69173 BIS6102 Business Process 3 RAEWYN 935 B

Management

69173 TA7000 Disputes Resolution 4 CHRIS 327 C

09667 TA7000 Disputes Resolution 2 KARIN 925 C

CHAPTER 4 Database concepts II 181

1NF with dependency arrows

Instructor Instructor Instructor

Student number Course number Course title number name location Grade

38214 TA6000 Tax Avoidance 1 JAMES 927 A

38214 BIS6103 Databases 2 KARIN 947 C

69173 BIS6103 Databases 5 DAVID 944 A

69173 BIS6102 Business Process 3 RAEWYN 935 B

Management

69173 TA7000 Disputes Resolution 4 CHRIS 327 C

09667 TA7000 Disputes Resolution 2 KARIN 925 C

2NF

Student table:
Student number

Course table:
Course number, Course title

Student course (enrolment table):

Student number, Course number, Instructor number, Instructor name, Instructor location, Grade

Note that instructor name is dependent on the primary key of the student course (enrolment
table) via the non-key attribute of instructor number. Instructor location is dependent on part of the
primary key (the course number attribute) and instructor number (a non-key attribute). Therefore,
we need to remove these transitive dependencies to achieve third normal form.

3NF

Student table:
Student number

Course table:
Course number, Course title

Student course (enrolment table):

Student number, Course number, Instructor number, Grade

Instructor table:
Instructor number, Instructor name

Course room allocation table:

Course number, Instructor number, Instructor location

182 PART 2 Systems characteristics and considerations

 Student number Student number, Course number, Grade, Instructor number Course number, Course name

Course number, Instructor number, Instructor location Instructor number, Instructor name

Required
(c) Explain the logic underlying the table; that is, how the university works given the above
change. Comment on the ER diagram.
4.4 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Sales order form No: SO-1545

To: Ms Margaret Sinu (Customer ref.: 672839)

1/56 Mount Waverley Road Perth 6523

Entered by: Approved by:

Mike Myers, Sales Department Zincal Sion, Sales Manager

Order date: Customer order no.:

01/04/15 Int-029389

Delivery speed: Shipping via: Payment method:

Normal Calmex Logistics Invoice customer

Remarks: NIL

Item no. Description Quantity

78293 Gigante CD-ROM 1

82838 Picole light pen 5

53564 Sanman computer pen 5 boxes

CHAPTER 4 Database concepts II 183

4.5 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation.(LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Credit application form No: 1002919

Please complete the required details below ensuring that all information supplied is true to the best of your
knowledge. Please circle where appropriate.

Personal details

Your full name: Your sex: M/F

Your home address: Your postal address (if different from home address):

Credit history

Status of home: renting / boarding / own home / How long have you been there?
other (please specify): Years      Months

State details of your assets (e.g. car, furniture, equipment etc.)

Description: Approximate value:
Description: Approximate value:
Description: Approximate value:
Description: Approximate value:

State your credit card details here:

Issuer: Card no.: Amount owing:
Issuer: Card no.: Amount owing:
Issuer: Card no.: Amount owing:
Issuer: Card no.: Amount owing:

Other liabilities:
Description: Amount owing:

Total monthly expenses (to the nearest dollar):

Please sign the declaration below:

The above details are correct and true to the best of my knowledge. I hereby authorise Australian
Information Company to supply my credit details to credit agencies to verify my creditworthiness.

Signed:                  Date:

184 PART 2 Systems characteristics and considerations

4.6 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Order acknowledgement form No: C15-2004

To: Ms Margaret Sinu (Customer ref.: 672839)

1/56 Mount Waverley Road Perth 6523

Date order received: Entered by:

01/04/15 Mike Myers, Sales Department

Order summary
Please carefully check the order details below and contact the sales department
if any details shown are incorrect.

Item no. Description Quantity Price/unit

78293 Gigante CD-ROM 1 $250.00

82838 Picole light pen 5 $ 60.00

53564 Sanman computer pen 5 boxes $  9.00

4.7 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

To: Ms Margaret Sinu (Customer ref.: 672839)

1/56 Mount Waverley Road
Perth 6523

Packing slip no.: Delivery date: Sales order no.:

P04-1592 15/04/15 SO-1545

Item no. Description Quantity

78293 Gigante CD-ROM 1

82838 Picole light pen 5

53564 Sanman computer pen 5 boxes

Remarks:

CHAPTER 4 Database concepts II 185

4.8 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Sales invoice No: 04-827383

To: Ms Marg Sinu (Customer ref.: 672839) 1/56 Wave Road Perth 6523

Order date: Date shipped: Sales order no.:

01/04/15 14/04/15 SO-1545

FOB: Shipping via: Terms: Other remarks:

Destination Calmex Logistics 2/10, n/30

Contact person: Jillian Jones, Sales Department

Item no. Description Quantity Price/unit

78293 Gigante CD-ROM 1 $250.00

82838 Picole light pen 5 $60.00

53564 Sanman computer pen 5 boxes $9.00

Subtotal $595 Freight charges $25

GST $62 (inclusive) Total amount owing $620

4.9 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Purchase requisition form No: 936

Data prepared: Prepared by: Date required:

15/07/15 Joseph Smith, 30/07/15
Purchasing Department

Suggested Contact person: Deliver to:

vendor: Jill Darci, Delivery Dock
Tech Supplies Purchasing Department

Item no. Description Quantity Price/unit

35930 Willow Series W laptop 1 $3500.00

computer

93948 Hume Premier paper, 10 ream 15 boxes $25.00

83748 Hyth HD diskettes, box of 10 15 boxes $7.50

186 PART 2 Systems characteristics and considerations

4.10 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Purchase order form No: 1545

To: Tech Supplies (Vendor Ref: 2839)

782 Mount Macedon Terrace
Victoria 3547

Order date: Delivery date: Purchase requisition no.:

17/07/15 26/07/15 936

Shipping via: Calmex Terms: Other remarks:

FOB: Destination
Logistics 2/10, n/30

Approved by: Contact person:

Item no. Description Quantity Price/unit

35930 Willow Series W laptop computer 1 $3500.00

93948 Hume Premier paper, 10 ream 15 boxes $25.00

83748 Hyth HD diskettes, box of 10 15 boxes    $7.50

4.11 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

782 Mount Macedon

Tech Supplies Terrace Victoria
Packing Slip 3547

To: Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Packing slip no.: Delivery date: Purchase order no.:

P03-0939 26/07/15 AIC-1545

Item no. Description Quantity

35930 Willow Series W laptop computer 1

93948 Hume Premier paper, 10 ream 15 boxes

83748 Hyth HD diskettes, box of 10 15 boxes

Remarks:

CHAPTER 4 Database concepts II 187

4.12 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Receiving report No: 1342

Order received: Purchase order no.:

26/07/15 1245

Shipper: Shipping weight: No. of packages:

Calmax Couriers 15 kg 3

Freight bill no.: Freight charges: Consignment?

– NIL Yes

Received and checked by: Delivered by:

Item no. Description Quantity Condition

35930 Willow Series W laptop computer 1 Good

93948 Hume Premier paper, 10 ream 15 boxes See below

83748 Hyth HD diskettes, box of 10 15 boxes Good

Remarks:
Hume Premier paper: One ream’s cover is torn, with paint on the top sheet. One ream will be replaced.
So only 14 copies of Hume Premier paper are received.

4.13 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Disbursement voucher No: 1458

Remit to: Tech Supplies (Vendor Ref: 2839)

782 Mount Macedon Terrace
Victoria 3547

Order processed: Prepared by:

26/07/15 Josephine Gillian

Vendor invoice Date Amount Returns and Discount Net amount

number allowances

67289 30/07/15 3792.50 NIL 379.25 3413.25

188 PART 2 Systems characteristics and considerations

4.14 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

EMPLOYEE DETAILS AMENDMENT FORM No.: 100/06

EMPLOYEE PERSONAL DETAILS

Date: Employee name: Employee department: Employee no.:

20/08/15 Smith Jones Purchasing department 1018292

HOME ADDRESS

Address: 181 Hilly Billy Street

City or suburb: Melbourne State: VIC

Postcode: 3005 Country: Australia

Is the above your mailing address? YES NO

(if not indicate your mailing address overleaf)

CONTACT

Home no.: (03) 8998 8998 Office no.: (03) 4334 4334

Mobile no.: 0459 999 999 Other: n/a

OTHER

Birth date: 15/08/1970 Sex: Female

Educational level: BCom. Citizenship status: Citizen

EMPLOYEE EMPLOYMENT DETAILS

EMPLOYMENT HISTORY

Job history (Note this cannot be amended. Contact the personnel officer.)

Date joined 15/01/2007 Pay level HE1 CLASS 2

organisation:

CHAPTER 4 Database concepts II 189

4.15 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003
EMPLOYEE PAY SLIP No: 10-828279
Employee no.:
81729
Department: Administration
Date Description Rate (per hour) Hours worked Total pay ($)
15/01/15 Project 1 56 7 392
15/01/15 Project 1 56 4 224
16/01/15 Project 1 56 8 448
Total pay before tax for period ending 16/01/15 1064
Tax withheld 345
Total pay deposited into bank account 699

Prepared by: Date entered: Pay period:

James Holland, pay officer 15/01/15 3-10

4.16 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

PURCHASE ORDER
No. 64971
Slick Sales
45 Westend Road
Melbourne
ABN: 57 999 888 777

TO: SENT
Office Supplies Ltd 05 MAY 15
5 Broadway Road
East Melbourne

Date Ordered: 5/5/2015 Purchase Req No.: 54937

Product No. Description Price Quantity Total
101-A1 A4 Copy Paper 500 sheets 5.50 10 55.00
202-C4 Printer cartridge – Laserjet 68.00 5 340.00
054-B2 Electronic stapler 75.00 2 150.00
391-J8 Paper files – pack of 100 35.50 4 142.00
452-P3 Binder – A4 2 ring large 6.75 2 13.50
TOTAL 700.50

Prepared By: Approved By:

Sam Toms Tim Lees

190 PART 2 Systems characteristics and considerations

4.17 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation.

RECEIVING REPORT
Slick Sales No. 68431

Purchase Order No: 64971 Entered By: Louise Hanninton

Goods Received From: Office Supplies Ltd Receipt Date: 12/5/15

Product No. Description Quantity Comments

101-A1 A4 Copy Paper 500 sheets 10 Condition OK
202-C4 Printer cartridge – Laserjet 5 Box damaged, item OK
054-B2 Electronic stapler 2 Condition OK
391-J8 Paper files – pack of 100 4 Condition OK
452-P3 Binder – A4 2 ring large 2 Condition OK

Report Goods
Prepared By: Received By:
Julie Mantini Ross Scambly

CHAPTER 4 Database concepts II 191

4.18 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

TAX INVOICE
No. 159473
Office Supplies Ltd
5 Broadway Road
East Melbourne
ABN: 10 567 893 111

To: Acct No.: S1149

Slick Sales Terms: 2/10, n/35
45 Westend Road Payment Due: 29/06/15
Melbourne

Invoice Date: 25/5/2015 Purchase Order No.: 54937

Product No. Description Price Quantity Total

101-A1 A4 Copy Paper 500 sheets 5.50 10 55.00
202-C4 Printer cartridge – Laserjet 68.00 5 340.00
054-B2 Electronic stapler 75.00 3 225.00
391-J8 Paper files – pack of 100 35.50 4 142.00
452-P3 Binder – A4 2 ring large 6.75 2 13.50
SUB TOTAL 775.50
+ GST 77.55
TOTAL 853.05

PLEASE QUOTE YOUR ACCOUNT NUMBER WHEN ENQUIRING ABOUT INVOICE DETAILS

REMITTANCE ADVICE
Please return with payment

Account Number: S1149 Due Date: 29/06/15

Account Name: Slick Sales Invoice No: 159473
Amount Owing: 853.05

OFFICE USE ONLY

Date Received: Date Entered:
Received By: Entered By:
Amount Received: Cheque Number:

192 PART 2 Systems characteristics and considerations

4.19 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

TRIMOND BANKING GROUP Date 30-05-15

Cheque 101 349 Victoria Avenue
Melbourne East
Payee: Office
Supplies Ltd
For: Office Pay Office Supplies Ltd Or bearer
Supplies Invoice 159473 The sum of Eight hundred and fifty-three dollars $853.05
and five cents
Date: 30-05-15 Slick Sales

Amount: 853.05
|| 648 317 101||

4.20 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

PURCHASE ORDER SUPPLIER

COPY
Giddy Up Pty Ltd No. 64971
1 Winning Post Lane
Flemington
ABN: 11 111 111 111

To:
Stable Supplies
4 Fetlock Road
Caulfield

Order Date: 1/11/2015 Purchase Req No.: 61111

Product No. Description Price Quantity Total

A-187 Barrier blanket 150.00 5 750.00
A-199 Riding crop 45.00 4 180.00
C-297 Racing saddle – light 300.00 1 300.00
G-851 Norton bit 80.00 3 240.00
TOTAL 1470.00

Approved
Prepared By:
By:
Mary Bethany Kym Dilaney

CHAPTER 4 Database concepts II 193

 4.21 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Serial Serial
Product Product number of number of Purchase Salesperson Salesperson Branch
description supplier product computer Sale date cost Sale price number name location

Herbal Jiffy 16604 113545 18/6/15 8.50 15.00 2 Heather Remuera

delights counted Alison
cross
stitch

4.22 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

PURCHASE ORDER RECEIVING

DEPT COPY
Giddy Up Pty Ltd
1 Winning Post Lane No. 64971
Flemington
ABN: 11 111 111 111

To: Received
Stable Supplies 07 NOV 15
4 Fetlock Road
Caulfield

Order Date: 1/11/2015 Purchase Req No.: 61111

Product No. Description Price Quantity Total

A-187 Barrier blanket
A-199 Riding crop
C-297 Racing saddle – light
G-851 Norton bit
TOTAL

Approved
Prepared By:
By:
Mary Bethany Kym Dilaney

194 PART 2 Systems characteristics and considerations

4.23 Transform this into third normal form. State all assumptions made and show all steps in the
normalisation. (LO1)

Employee Employee Employee Employee Factory

number name department grade Location Factory name Employee title

9056 John Yourdon Factory F6 Northland Maui Leading Hand

FURTHER READING
Chen, PPS 1976, ‘The entity–relationship model: toward a unified view of data’, ACM Transactions on
Database Systems, vol. 1, no. 1, pp. 9–36.
Codd, EF 1990, The relational database for database management, Addison-Wesley, Reading, MA.
Coronel, C & Morris, S 2015, Database systems: design, implementation, and management, 11th edn,
Cengage Learning Inc., Boston, MA.
Coronel, C, Morris, S, Rob, P & Crockett, K 2013, Database principles: fundamentals of design,
implementation, and management, 2nd edn, Cengage Learning Inc., Boston, MA.
Gillenson, ML 2012, Fundamentals of database management systems, Wiley, Brisbane.
Gillenson, ML, Ponniah, P, Kriegel, A, Trukhnov, BM, Taylor, AG & Powell, G 2008, Introduction to
database management, John Wiley and Sons Inc., New York.
Hoffer, JA, Ramesh, V & Topi, H 2013, Modern database management, 11th edn, Pearson Education,
Boston, MA.
McCarthy, WE 2003, ‘The REA modelling approach to teaching Databases’, Issues in Accounting
Education, vol. 18, no. 4, pp. 427–41.
Satzinger, J, Jackson, R & Burd, S 2012, Systems analysis and design in a changing world, 6th edn,
Course Technology, Cengage Learning Inc., Boston, MA.
Sciore, E 2009, Database design and implementation, John Wiley and Sons Inc., New York.

SELF-TEST ANSWERS
4.1 a, 4.2 b, 4.3 a, 4.4 c, 4.5 b, 4.6 a

CHAPTER 4 Database concepts II 195

ENDNOTES
1. Hoffer, JA, Ramesh, V & Topi, H 2013, Modern database management, 11th edn, Pearson Education, Boston, MA.
2. McCarthy, WE 1982, ‘The REA Accounting Model: a generalized framework for accounting systems in a shared data
environment’, The Accounting Review, July, pp. 554–77.

ACKNOWLEDGEMENTS
Photo: © Courtney Keating / iStockphoto.

196 PART 2 Systems characteristics and considerations

CHAPTER 5

Systems development
LEA RNIN G OBJE CTIVE S

After studying this chapter, you should be able to:

5.1 exhibit judgement in explaining how business size and complexity may influence the choice of
systems development strategy for an organisation
5.2 summarise the stages of the systems development life cycle and critically evaluate the importance of
organisational strategy as the basis for systems development
5.3 compare and contrast alternative approaches to systems development
5.4 describe the software development options available to smaller businesses and demonstrate how this
knowledge can be used to outline the systems selection processes for decision making
5.5 recognise typical systems development problems and propose solutions for their resolution
5.6 critique and describe some common systems development tools.
Introduction
Systems development is an important part of the organisation. Information technology (IT) represents
the way that an organisation recognises the need for a new system, goes through the process of meeting
that need and implements the system within the organisation. Systems development is a project for an
organisation, the outcome of which is intended to be a better system that allows the organisation to
function more effectively. Organisations face the need for systems development for various reasons,
including the following.
•• An existing system has reached the end of its usefulness and is in need of replacement because of
outdated technology or slow processing time.
•• A new strategic opportunity has been identified that will allow the business to improve its strategic
position (e.g. linking the system with a customer or supplier to increase efficiency of transactions and
strengthen relationships).
•• The business is just starting out and has no systems in place.
Whatever the reason for the systems development, organisations need an approach that they can
employ in their systems development activity. This chapter emphasises the traditional approach, that of
the systems development life cycle. The chapter introduces the stages of the traditional systems devel-
opment life cycle as well as the newer adaptive and iterative methods. The prototyping process, the
application service provider and some common problems in systems development are discussed. Many
texts have been written on systems development as a stand-alone topic. This chapter is intended as an
overview to the area, to promote thinking about systems development within the organisation. Different
organisations will use different frameworks or pick and choose aspects of differing frameworks, so it is
important, as an accountant, to have an understanding of what is happening and why under the differing
frameworks. As well as understanding differing frameworks for systems development, the accountant
will play different roles within the systems development process, for example, as a user of the final
system or as an auditor of the system. The references at the end of the chapter are a useful source of
topics for further discussion.

198 PART 2 Systems characteristics and considerations

 In recent years, the management of systems development within the organisation has been a critical
issue as businesses have upgraded systems, implemented new systems or looked for add-on systems,
such as CRM (customer relationship management). The adoption of an enterprise resource planning
(ERP) system is an example of an organisation-wide systems development effort. Such effort requires
careful management and consideration. This chapter aims to introduce some of these considerations in
the systems development effort of an organisation.

5.1 Business size and complexity

LEARNING OBJECTIVE 5.1 Exhibit judgement in explaining how business size and complexity may
influence the choice of systems development strategy for an organisation.
Table 5.1 splits Australian and New Zealand business into three broad classifications (large, medium and
small) based on size (number of employees) and turnover, and indicates appropriate levels of sophis-
tication of accounting systems. The classifications are arbitrary and the specifications of systems are
generalisations: in some cases a firm with $10 million turnover and 50 employees may find that a simple
package meets all its needs, while another organisation of similar size may consider that the additional
cost and complexity of an ERP system is justified by the unique features of its business.
Choosing an accounting system is not a one-size-fits-all exercise. The complex, time-consuming and
expensive process described in the next section, while absolutely essential for the successful implemen-
tation of an ERP system, goes well beyond the needs of medium and small businesses. A simpler meth-
odology for system selection for these businesses is described later in the chapter.

TABLE 5.1 Australian and New Zealand business size classifications

Small Medium Large

Number of employees 1–20 21–200 201+
Annual turnover <$5 million $5–$50 million >$50 million
Accounting system Simple Mid-range ERP

5.2 Systems development life cycle

LEARNING OBJECTIVE 5.2 Summarise the stages of the systems development life cycle and critically
evaluate the importance of organisational strategy as the basis for systems development.
The systems development life cycle has parallels with any other life cycle that you can think of. It rep-
resents the stages that are followed in the design, implementation and maintenance of an information
system within an organisation. As the subsequent sections reveal, the systems development life cycle
offers a structured, well-controlled and well-documented approach to systems development. This con-
trol and this structure can be important for managing large systems development projects and can also
be a way of ensuring that available resources for the systems development effort are maximised. The
systems development life cycle is the most popular and traditional method of systems development.
Alternative methods of systems development — prototyping, object-oriented analysis and agile/adaptive
methods — will be covered in the next section. These methods are labelled as alternatives and may be
employed as such, but many of the methods are also based on the systems development life cycle. The
reason for their popularity is because the systems development life cycle can be costly, take longer
than budgeted for and not satisfy the user requirements. Therefore, these alternative methods have been
developed to try to counter concerns with the traditional systems development life cycle. However, none
of the other methods have a higher success rate than the systems development life cycle.
The systems development life cycle consists of five stages: (1) investigation, (2) analysis, (3) design,
(4) implementation and (5) maintenance and review. In different texts you will find they are labelled

CHAPTER 5 Systems development 199

differently and consist of a different number of phases. For example, the investigation phase may be
called survey; there may be analysis, design, select software and hardware; maintenance may be a
separate phase, with post-implementation review a separate phase after maintenance. Generally, we will
discuss the phases as we have listed them, but be aware different phase names can occur.
In the investigation and analysis stages, the problems facing the organisation are investigated in light
of the current system and its operations. Alternative responses for the problem will be evaluated based
on their feasibility. After selecting the most feasible option, the design for that option will commence,
with this consisting of both logical and physical design perspectives. After the design is complete, the
system will be physically implemented and, once implemented, will require regular maintenance and
review. As figure 5.1 shows, the cycle begins with investigation, then analysis, design, implementation,
and lastly maintenance and review. Once the maintenance and review part of the life cycle can no longer
successfully maintain the system, the cycle will start again with investigation. This, from a simplistic
view, makes it a circular process. Think of the development of the Microsoft Office Suite of products,
for which a new version comes out every two to three years. This would require implementation of the
new version every two to three years. Note, however, that it can be an iterative approach where flows
move back and forth between stages until it is deemed appropriate to progress to the next stage.

Investigation

Maintenance
Analysis
and review

Implementation Design

FIGURE 5.1 Systems development life cycle

As the following sections describe, each of these stages has predefined inputs and outputs. The out-
puts of each stage provide the inputs into subsequent stages, thus building a control into the systems
development effort. The control of the life cycle arises because latter stages cannot commence until
earlier stages have been signed off. As a result of this built-in control over stage commencement, a
degree of accountability is built into the systems development life cycle. Participants involved in a sys-
tem’s development require their superiors to sign off on their work before proceeding to later tasks, and

200 PART 2 Systems characteristics and considerations

steering committee members will typically sign off on a stage before progress to the next stage occurs.
This strength of the life cycle is characterised by its controlled and structured approach. The require-
ments for each stage are set up and the stage must deliver those requirements. The internal auditor needs
to be involved in each stage of systems development to ensure that adequate internal controls are built
into the new system as it is designed. However, as the example of Very Limited in figure 5.2 illustrates,
the limitation of the traditional approach to systems development is the time involved.

June, the accountant for Very Limited, just wants the new system. She is concerned with all the time the
systems development people are taking. She books a meeting to discuss why they aren’t just designing
the new system. Sue from the IT development team explains that there are several steps they need to
take. To figure out the requirements of the new system they must analyse the old system; that is, before
they can establish what the new system should do, they first need to establish what the old system
actually does. These steps are part of the systems development life cycle. Sue explains that each step
has inputs and outputs and by following these steps June and the other system users in the organ-
isation will get the system they need. June explains that it is also important for users to understand
each of the steps in the life cycle and the inputs and outputs of each step, so they know what they need
to contribute. Proposing a solution without investigating the problem, scope and current system may
cause problems later. The worst case could be that the solution (new system) does not fix the problems
and doesn’t even do what the old system used to do. So, even though the systems development is
taking time, the time spent is valuable in getting the right result.

FIGURE 5.2 Very Limited example

The issue discussed in figure 5.2 is one of time. The traditional systems development process requires
people involved in the analysis phase to spend a lot of time looking at what the current system does. This
is important if the system has particular processes which need to be understood so that the new system
can replicate them. However, if completely different processes are involved, spending a lot of time ana-
lysing the old system will lead to what is called ‘analysis paralysis’. If the new system is different, then
looking at the old system may not be helpful. However, the traditional systems development life cycle
does include the analysis phase, which looks at what currently exists before it considers what the new
system should look like. The alternative approaches discussed later in the chapter endeavour to counter
these issues with the traditional systems development process.
The following sections discuss the stages in the systems development life cycle.

Investigation
The investigation phase of the systems development life cycle is concerned with identifying any prob-
lems or opportunities with the current systems and the feasibility of responding to these problems or
opportunities. Notice that the trigger for a systems development effort can be either a problem or a per-
ceived opportunity. The point in emphasising this is that systems development is not triggered solely by
the advent of a problem in the existing systems, for example, the processing speed being inadequate and
the process throughput time being slowed down as a result. A perceived opportunity for the business can
be a trigger in itself for a systems development project. A perceived opportunity in this context refers to
a means by which the organisation can use its existing resources, or acquire new resources, to enable it
to build on its existing strategy and increase its competitive advantage within its industry.
An example of an opportunity can be seen in the process used by supermarkets in their checkouts.
Before the advent of computers, supermarkets manually processed items through the checkout, with sales
staff keying prices into manual registers that kept a total of all purchases. As computers and database tech-
nologies emerged and became widely accessible to business, these manual registers were computerised,
requiring staff to enter product codes, which were then captured by the register and looked up in the data-
base of products to find a price for the items being purchased. This made the checkout process quicker.

CHAPTER 5 Systems development 201

 A further advance came with barcode scanning technology, allowing the quicker capture of data about
products being purchased. Instead of product codes having to be keyed manually into the register, bar-
codes from products could be electronically read by scanners, enabling an even faster and more accu-
rate checkout process. Similarly, connecting electronic scales to the point-of-sale terminal allowed the
checkout operator, using only the product look up (PLU) code or a name, to have the system look up a
price per kilogram for fruit and vegetables. These simple examples of technology evolution show how
businesses are able to benefit from new technologies and develop new systems around the technology.
Extending the technology even further, self-service checkouts have been successfully introduced into
supermarkets in many countries, including Australia and New Zealand. A possible future advance might
involve radio-frequency identification (RFID) tags being attached to all products and the trolley being
equipped with a reading device that would calculate the amount due as each item was loaded in. There-
fore, systems development is not just about identifying the problems with the existing systems; it is also
about being aware of new technologies and how they can be used to create advantage for the organisation.

AIS FOCUS 5.1

Supermarkets changing the way you shop

Research told supermarkets that the main focus for customers was accuracy and efficiency when pro-
ceeding through checkouts, as opposed to a warm interpersonal dialogue with the checkout attendant.1
Recognising this, supermarkets increasingly introduced self-serve checkouts as a way of reducing
queue times for customers — especially those purchasing only a small number of items (on average,
customers using the self-serve checkouts have six items, while those using the regular checkouts have
14).2 While the supermarkets were conscious of the fact that not all consumers would want to use the
automated checkouts — some prefer the interaction with the checkout attendant or are resistant to the
technology — a number of customers willingly used the self-serve option.3 The technology potentially
offered supermarkets a new avenue for competing — while stores vie for patronage based on grocery
prices, the potential to compete on customer time4 (which some would say is equally, if not more,
precious to shoppers) added a new dimension to supermarket competition. However, since most super-
markets now offer it, self-service is generally considered a standard service.
When introducing the self-serve checkouts originally, the supermarkets engaged a range of stake-
holders in discussion. For example, it was reported that Woolworths consulted with the unions during
the various stages of developing the self-checkout system.5 Such consultation was presumably to allay
concerns that the use of the technology would replace checkout staff with machines.
Taking this innovation further, an independent chain of supermarkets is exploring a technology that
sees a shopping trolley fitted with an LCD screen, keypad and barcode scanner. The hi-tech trolleys
allow customers to scan items as they shop, giving them totals for the items in the trolley. This avoids
nasty surprises when they get to the checkout. It also allows the trolleys to be tracked via wireless
technology, enabling the customer to enter items and the system to tell them where they are located
within the store and how much they cost. This technology is enabled by the application of a wireless
network throughout the store. The technology can also be expanded, with customers entering a shop-
ping list online before leaving home, and then, by swiping a card through the trolley device, having the
device display the list and guide the shopper through the store to find their nominated items. The tech-
nology could offer several benefits for stores, including a more personalised, efficient and user-friendly
shopping experience for the customer and the ability to generate advertising revenue through displays
on the LCD screens.6 Adding to their revenue-generating ability, the trolleys could track the shopper’s
movements throughout the store and, as they progress up and down the aisles, display items that are
on special and located nearby, bringing them to the customer’s attention.7

The critical point to keep in mind when considering new opportunities for technology within the organ-
isation is the issue of organisational fit. Organisational fit refers to how well the technology is aligned with
the overall organisational strategy and strategic priorities. This is an important point to bear in mind because
it emphasises the idea that technology should be used to tackle problems and opportunities that originate
within the business. The relationship does not work in reverse, that is, not all new technologies are blindly

202 PART 2 Systems characteristics and considerations

adopted even if there is no real application for them or they conflict with overall organisational strategy and
mission. Therefore, consider new technologies in light of the underlying business environment — new tech-
nologies are not necessary for all businesses. It is the matching of the technology to the opportunity that is
important, not just blind adoption of technology because it is seen as the ‘cool thing to do’.
Therefore the investigation phase involves three main issues:
•• problem identification
•• scope of the problem
•• feasibility of fixing the problem.
It could also involve some work-breakdown investigation, which would look at what should happen in
the following phases and how long each of the tasks should take.
These issues are very important because, before going on to the analysis phase, we should have iden-
tified the problem and it should be agreed on by all parties. We should know the scope of the problem
we are solving — is it accounts receivable, or accounts receivable and inventory? We should also have
evaluated the feasibility of fixing the problem and found that it is feasible overall to continue. In other
words, we should know what problem we are fixing, that it is worth fixing and how long each phase
should be up to development plans to fix the problem.

Problem identification
Problem identification will usually involve those working on the system development and a user rep-
resentative group. The user representative group will consist of a cross-section of employees from dif-
ferent parts of the organisation who are able to provide feedback, on behalf of their colleagues, about a
system’s operation. As an accountant, you may be required to be a member of such a user representative
group. Therefore, it is important to understand the goals of the problem identification phase and how you
can contribute to the system development. Problems with existing systems can be identified in several
ways. One way is through user and stakeholder feedback, which can take the form of formal and informal
comments that have been received from those involved in a system’s operation. For example, telephone
operators at a booking centre may alert those in charge to a slow system that takes an excessive amount
of time to process ticketing requests from customers who are waiting on the other end of the line. As
another example, customers may complain to an organisation about a system that bills them incorrectly.
This feedback will typically be provided ad hoc as problems or issues emerge in the systems operation.
Alternatively, a periodic review of system operations can identify systems opportunities and prob-
lems. An example of an event that may have triggered systems development is the introduction of the
Sarbanes–Oxley Act in the United States. Many companies faced issues of legislative compliance after
the introduction of the Act, prompting them to review their existing system’s internal controls and poten-
tially design a new system that was compliant. In Australia, the introduction of the goods and services
tax (GST) meant that businesses had to revisit their accounting system and ensure it was compliant with
the recording and reporting obligations that arose from the change in the tax legislation. Other factors to
consider when investigating any problems or opportunities with a system include system speed, system
adequacy, system support, new changes and general triggers. Each of these is now discussed briefly.
•• Is the speed of the system adequate for its current role? As organisations grow, so too will the amount
of data that they handle and store. This can place increased demands on existing systems and may
provide a trigger for systems development. In the supermarket example mentioned above, the speed
of transaction completion at the checkout was a major motivation behind the series of developments
mentioned. In each case, the changes increased the speed at which the system could capture and
process data about sales. Other examples may include new data access and storage techniques that
allow for faster systems.
•• Does the system adequately handle the events that occur in a process? Information systems are put in place
to support the operations of the organisation. The design and operation of the system should be driven
by the organisation’s needs. To this end, as the organisation changes, so too will the requirements of the
information system. Growth in customer numbers may mean that old systems become slow and inadequate

CHAPTER 5 Systems development 203

 for the fast processing of customer requests. From an organisation’s perspective, it can be useful to identify
the key events that occur within a business process and then assess how well the information system handles
these events. This can be a powerful way to identify any problems in the current system.
•• Is the system able to generate the required information to support management decision making? The
system’s role within the organisation should be to gather data from business events and allow for the
summarising of these data into meaningful and useful information that supports management decision
making. Feedback from managers that they need a new type of information or a new report or have
other new requirements can be a trigger for systems development activities.
•• Are there predicted circumstances that may require a change to the current system? Several examples
of systems development have been triggered by anticipated future events. Two are the ‘year 2000’
problem and the introduction of the GST. The year 2000 problem — the possibility that older systems
would not be able to recognise the 2000 date because of a two-digit year rather than a four-digit year
in systems data — prompted many organisations to undergo major systems development efforts as
they may not have been able to process transactions. At that point, old mainframes that had been
functioning for years without issue were upgraded through major systems development projects, many
of which included the adoption of ERP systems.
In Australia, the change in the tax legislation that saw the introduction of the GST on 1 July 2000
prompted many systems development efforts. (In New Zealand, the change was much earlier, in 1986
(10 per cent GST rate), with a GST rate change in 1989 (to 12.5 per cent) and a second rate change
in 2010 (to 15 per cent). Many organisations were forced to review the operation of their existing
information systems and, where necessary, change them or upgrade them so that they could handle the
new taxation environment, which brought with it new requirements for data gathering and statutory
reporting. Many commercial producers of accounting packages recognised this need by producing
GST-compliant accounting software. As well as being GST compliant, the software needed to be able
to accommodate rate changes at a specific date in time.
•• Has there been an event that would trigger concerns about the current system? Events within the
organisation may also act as a trigger for systems development, including the failure of existing
systems (e.g. a processing system that crashes frequently), the occurrence of organisational fraud
owing to inadequate information controls, or rapid growth that has made the old systems inadequate
for the new operating environment. One example is the advent of the e-commerce environment.
Organisations that make the decision to support the avenue of e-business face associated issues of
ensuring that existing systems support this environment and, where necessary, development occurs
to support the e-commerce operations. This could include the development of web interfaces and
environments that support the integration of the new e-commerce environment within the existing
systems environment. Alternatively, a business may expand and acquire a subsidiary, which could
then bring about the need to prepare consolidated financial reports. This may require that the financial
reporting systems of the parent and subsidiary be integrated, or operate on a common platform.
Other ways of identifying avenues for potential systems development can include surveying existing
users regularly, observing the system in action by watching users, and interviewing key users of a
system. These provide first-hand information on the operation of the system and, as is discussed later in
the chapter, can also provide the users with the perception that they are involved in, and an important
part of, systems development within the organisation.
Once the information has been gathered, a report detailing the problems and opportunities will be pre-
pared, which will form the basis of the investigation of alternative ways to solve the problems or exploit
the opportunities.

Problem scope
Once the problems with or opportunities of the existing system have been identified, the organ-
isation must develop ideas for how these problems or opportunities can be met. The first step in doing
this is to define what the systems development project will cover. This is the critical issue of defining the

204 PART 2 Systems characteristics and considerations

systems development scope. For example, is the scope of the system a sales order, or a sales order and inven-
tory system? Several problems may have been identified but not all of these may be high priority. Defining the
scope of the system helps in clarifying what the systems development effort is aiming to achieve and reduces
the risk of heading off on tangents that do not solve the identified problems. From an accounting perspective
of the system, the scope defines the systems development effort and what it aims to achieve; anything outside
this scope is not attempted by the systems development effort. As a result, it is important to ensure that the
scope covers the identified problem, as the scope cannot be varied once the project is underway.
Feasibility
Feasibility will determine whether something will actually occur. The feasibility analysis involves evalu-
ation of the alternatives identified to determine whether they are legitimate options for the business to con-
sider at later stages of the development. Feasibility will be assessed on five dimensions: financial (sometimes
called economic), legal, schedule, technical and strategic (sometimes called organisational) feasibility.
Financial feasibility
Financial feasibility is based around the economic costs and benefits of a system. In assessing the
financial feasibility of a system, the costs involved in adopting the new system will be systematically
compared with the financial benefits of the new system. Costs can include items such as consultants’
fees, the purchase of new hardware, software and equipment, and the costs associated with training staff
in the operations of the new system. Financial benefits of a new system can include the cost savings that
may arise, for example, reduced wages if a system automates a previously manual process, along with
any increases in sales or revenue that may arise. Note, however, that it is typically far more difficult to
estimate the benefits of a system in financial terms. This problem arises from the difficulty in directly
attributing any changes in organisational performance to a new system. For example, if a new system is
introduced and sales increase, does all of the increase relate to the new system? Additionally, benefits
typically require evaluation. In contrast, costs are usually easily identified and able to be determined to
a relatively precise degree. As a result, if one were to rely on financial feasibility alone, most projects
would face rejection at this early stage.
Another factor to consider when assessing the financial feasibility of a system is the concept of the
total cost of ownership. This refers to a need to consider not just the initial costs of installing a system
but also the ongoing costs following the implementation of a system. It is estimated that only 4 per
cent of executives realise that these post-implementation costs represent the largest component of IT
costs, often representing up to 80 per cent of total costs for a system.8 These costs are driven by three
areas: people, processes and technology.9 ‘People’ refers to making sure that the users of the system are
adequately skilled to use the system as it was intended to be used. Process costs relate to the configur-
ation of the system to meet the processes of the organisation, and can include the cost of removing old
processes and reconfiguring them to match the newly adopted technology. Technology costs refer to the
costs of acquiring the necessary technology to implement the proposed solution.
The costs and benefits of each alternative will be assessed through a financial feasibility report, which
will summarise the financial perspective over several years, incorporating both initial and ongoing costs
associated with a system. Advanced techniques may also use a discounted cash flows model, allowing
the time value of money to be taken into account. This can also allow the assessment of investment
alternatives based on their net present value, or the use of concepts such as internal rate of return. These
concepts are beyond the scope of this text and can be found in any good introductory finance text.
Legal feasibility
Legal feasibility is concerned with how the proposed system would operate given the legal environment
faced by the organisation. The legal environment refers to the laws and regulations an organisation is required
to comply with. This can include reporting obligations, for example, companies have reporting obligations
imposed on them under the Corporations Act 2001 of Australia or the Companies Act 1993 in New Zealand,
as well as the legality of the systems operation techniques. Examples of reporting requirements could be
a company that is considering the adoption of a new system but is not able to prepare reports according to

CHAPTER 5 Systems development 205

generally accepted accounting principles (GAAP) and International Financial Reporting Standards (IFRSs).
The preparation of these reports is a major part of the company’s reporting obligations and to meet these
obligations the system should be able to comply with GAAP. Therefore, a system that could not meet GAAP
requirements may be rejected on the legal feasibility criteria.
The other aspect to the legality of a system is the legality of its operations. Examples here could
include the way the system gathers, stores and uses data, and how, for example, these activities fit within
the Privacy Act.
Schedule feasibility
Schedule feasibility refers to the ability of the proposed solution to be implemented within the period
of time that is specified by the organisation. A project that takes two years to implement for a problem
that the organisation wants solved in three months will fail the test of schedule feasibility. The assess-
ment of schedule feasibility requires the assessment of the expected project time and a comparison of
the expected time with the time available. Estimating schedule feasibility requires a thorough under-
standing of the tasks that need to be performed and an estimate of their time for completion. Some tools
that can be used to assist in estimating schedule feasibility, as well as for controlling projects once they
are undertaken, include programmed evaluation review technique (PERT) charts and Gantt charts.
These tools are discussed later in this chapter.
Technical feasibility
Technical feasibility involves the assessment of how well the organisation’s existing technology infra-
structure meets the requirements of the proposed alternative. If the current resources are unable to meet
the requirements of the new system, an assessment of what new technology is required may also be
performed. This stage involves the consideration of different design options for the proposed alternative
and weighing them up against the organisation’s existing technical resources and the resources that are
available for purchase.
Strategic feasibility
Strategic feasibility refers to how well the proposed systems development alternative fits with the organ­
isation’s existing operating environment and strategy. You should recall the importance of being clear about
an organisation’s strategy and business process design as mentioned earlier in this chapter and in chapter 2.
One of the issues that needs to be considered is how well the proposed system alternative meets this stra-
tegic position. For example, a firm that has built up a position as a quality differentiator, offering customers a
highly personalised and quality-driven service, would not be keen to adopt a system that was built around the
principles of a cost leadership strategy. Why? Because the system would conflict with the strategy. On the one
hand, the organisation would have a strategy and set of business processes designed to serve the quality dif-
ferentiator position, while, on the other, the organisation would be adopting a system that functioned in sup-
port of a contrasting strategy. This situation can only create confusion for the organisation and its customers,
and has been a common problem in the adoption of ERP systems in organisations, because they discovered
that the business processes embodied within the ERP systems did not fit with the pre-existing organisational
strategy. The result was that the business strategy was undermined when ERP systems were adopted.
Once the project’s feasibility in each of the five areas has been evaluated and documented, a decision must
be made on whether to proceed with the systems development. This decision will be made on the overall
feasibility of the system alternatives based on consideration of the five dimensions discussed in this section.
The overall feasibility will be summarised and forwarded to the organisation’s systems development steering
committee, discussed in the next section, which has the task of selecting an alternative.
Determination of feasibility
The task of selecting the most feasible alternative rests with the systems development steering com-
mittee, which represents a key part of the systems development process. The members of the systems
development steering committee typically occupy positions of power throughout the organisation. The
systems development steering committee is responsible for determining whether the systems devel-
opment project should proceed. Since the steering committee decides on the project’s approval, the

206 PART 2 Systems characteristics and considerations

members should have the power to allocate resources throughout the organisation because once a project
is approved it requires financial and other resources for its successful completion. The job of the steering
committee is to select the alternative that it views as the most viable. Once selected, the committee will
sign off on the selected option, with this forming the basis of the design stage. The steering committee
also performs a critical role throughout the life cycle of the project, receiving reports at the end of each
major phase and signing the phase off so that the next phase can commence.
After the investigation phase is completed and the project deemed feasible by the systems develop-
ment steering committee, the analysis phase commences.

Analysis
The analysis stage of the systems development life cycle has two key parts. The first is to understand
what the current system does and how it operates. The second part is to specify what the new system
will need to do. The understanding of the current system is called the systems analysis, while the specifi-
cation of what the new system needs to do is called the requirements analysis.10 The requirements iden-
tified will be suggested by the needs of the end-users of the system. As users of an information system,
accounting personnel will be required to identify their needs.
Requirements analysis and specification
Systems analysis requires a thorough understanding of the current system, its operations and its design.
There are several ways that this understanding can be gained. One method is to analyse the systems docu-
mentation, which can include the process map, logical data flow diagram, physical data flow diagram,
systems flowchart and any other documentation that may exist within the organisation (see chapter 7
for a general discussion of systems documentation and chapters 10 to 12 for examples of systems docu-
mentation for specific business processes). If no such documentation exists, it can be useful to gen-
erate it before progressing because it provides a way of understanding how the current system operates.
Understanding the system requires an appreciation of the logical processes that occur in the system, the
physical entities that are involved in the processes, the documentation and data flows that occur in the
system and the interaction across the organisation that takes place: this is the impact of organisational
structure and design on the operation of the system and the flows across the organisation that occur.11 As
mentioned in chapter 2 on business processes, documentation techniques allow these various aspects of
a system to be shown. This analysis can help identify what the current system does, as well as how the
system needs to be changed. If using existing documentation, it is important to ensure that this remains
accurate, since procedures are often changed over time without the documentation being updated to
reflect the changes. In many cases, the accountant or internal auditor will have used logical and physical
data flow diagrams and systems flowcharts to document their systems; these can be used as a basis of the
systems documentation. With their understanding of the techniques in producing data flow diagrams and
flowcharts, the accountant can also evaluate any documents produced by the systems development team
to verify their understanding of the existing system or potential new system.
Requirements analysis then necessitates going from an understanding of what the current system
does to what the new system needs to do. Essentially, this is about understanding what the system is
required to do and how the different users use and interact with the system.12 It is also about how the
existing system can be improved, making a thorough understanding of the operations of the current
system an important starting point. There are several ways that this information can be obtained. As a
starting point, it is useful to speak to the key users of the system to understand how they use the system
in their roles and what features they regularly use or seldom use. Different users in an organisation
can include those involved in direct data entry, managers who use reports or output from the system
and any other stakeholders who may have a role in using the system. This can present the analyst with
challenges because different users or stakeholders of a system can have different views on requirements.
Additionally, what the stakeholders see as a requirement is often linked to the context of the organ-
isation that they are involved in, thus making requirements analysis a technical task (what the system

CHAPTER 5 Systems development 207

needs to do) and a social task (the impact of organisational structure and individual roles). This can
present the analyst with unique challenges.13
There are several techniques for gathering requirements information, including questionnaires, observ-
ation, interviews and prototyping. When a questionnaire is used, a survey is given to the different users,
asking them about the features of the system and what they use and do not use in a system. For example,
a survey to managers may ask them which of the reporting features they regularly use and which they
do not. This helps to gain an understanding of the important features required in a system. When writing
questionnaires, there are two options for the question style: open-ended and closed. Questionnaires
can be designed so they are open-ended, in which case the user can write responses and elaborate on
answers. Alternatively, a questionnaire can contain closed questions, which limit the nature of the res-
ponses that the user can give. Another option is for the systems analyst to observe the process in action
or be a part of the business process and a part of its operation. This will provide them with first-hand
experience of the operations of the process, the types of problems that may occur and what different
users need. Another alternative is to generate a prototype, based on the earlier investigation specifi-
cations, and involve users in the evaluation of the different features of the prototype. Prototyping for
systems development is discussed in more detail later in the chapter.
Having gained an understanding of the current system, spoken to users about its operation and elicited
suggestions for change, a list of requirements that the systems development needs to fulfil is generated.
This is a description of what the new system will need to do in the organisation. From the accounting infor-
mation systems perspective, some of the issues that may be evaluated at this point include the following.
•• What information do the different users require to perform their functions?
•• What is needed for the business process to integrate successfully with other systems and business
processes within the organisation?
Care needs to be taken when analysing requirements that the scope of the systems development effort
is realistic. Users, when asked, may offer suggestions that are beyond the scope of the current systems
development effort. Alternatively, they may make suggestions for things that do not add much improve-
ment to the system.
Eliciting the needs of the various users and determining what the new system is required to do is used
to provide some structure when designing the new system. It also helps in relating the objectives of the
systems development back to the original scope of the problem and the overarching business context and
strategy. It is also important to keep in mind the things that are important to the business and make sure
that the systems development and, in particular, the requirements specification are consistent with the
original scope of the project. Having done this, a design needs to be arrived at for a system to achieve
these aims. This is referred to as the design phase, and is discussed in the next section.
Once the analysis phase is complete, the documentation is reviewed by the steering committee to
ensure the analysis and the scope of the project fit in with the company’s plans. The steering committee
could decide at this point that the project should not commence.

Design
Once a systems development project has been deemed feasible and signed off by the steering committee,
the task is to design the system. System design can take two perspectives: the logical perspective and
the physical perspective. The logical perspective of systems design is concerned with a design that is
independent of the actual technology required for its implementation. The physical design requires speci-
fication of the technical aspects. The logical design, also referred to as the conceptual design, describes
what the system will do; the physical design describes how it will actually be done.
This is much the same concept as for the logical and physical data flow diagrams shown in chapters 10
to 12. To use an analogy, the logical design is like drawing a floor plan for a house — it contains the key
features such as the number of rooms, location of the bathroom and so on, while the physical design is
how the house will actually be built, for example, will it be made of bricks or timber, will the windows
be single or double glazed?

208 PART 2 Systems characteristics and considerations

 In this phase, the internal auditor needs to be involved as internal controls need to be built into a
system at the time it is designed, not later. Building in internal controls later is a costly and inefficient
process compared to building them in at the time the systems development occurs.
Determine outputs
Following the investigation and analysis stages of the systems development life cycle, we would be familiar
with the different user requirements. In particular, we would be aware of the types of outputs users require
from a system to complete their daily tasks. The understanding of these outputs is crucial to the design of
the system. Typical systems design theory recommends starting from the systems outputs as the basis for
designing the system. At first this may seem a little back-to-front; however, if you think about it, the prop-
osition is not so nonsensical. By starting with the required outputs of the system we are determining what
we need to get from the system. It is only by understanding what we want from a system that we are able to
clarify what inputs the system will require and how the input data must be processed. By starting from the
outputs we can work backwards to identify the necessary inputs. This flow back from outputs helps to ensure
that the new system is able to do what the users require it to do and generate the necessary information.
Determine inputs
Once it is clear what outputs are required from the system, it is possible to work backwards and determine
what inputs are required to generate the specified outputs. As part of designing the inputs, reports are decon-
structed, breaking them down into the different pieces of data that go into their generation. In determining the
inputs into a system, the designers need to understand the processes that the system will perform and the dif-
ferent data that are generated within those processes. One way to gain an understanding of this is to examine
the processes based on where data come from, the form they come in and how they are used within the
system. This can include looking at existing source documents within the system and any electronic data that
may be received from other sources, as well as how forms are used by participants working with the system.
An example of working backwards from outputs to inputs is shown in figure 5.3, which shows the
process of working backwards from a report, in this case a monthly sales report by customer, to the
inputs required to generate the report.

SALES REPORT BY CUSTOMER

Month CUSTOMER DATA

Number Name
Customer Jan Feb Mar TOTAL 02 Hughes, D.
03 Miles, B.
D Hughes 120 100 380 600 04 Smith, A.
B Miles 75 150 68 293 05 Tully, B.
A Smith 150 200 270 620 Requires
B Tully 180 80 120 380 data on
SALES DATA
Sales No Name Date Amt
TOTAL 525 530 838 1893
0004 Hughes, D. 01/01 60
0005 Miles, B. 05/01 75
0006 Smith, A. 09/01 150
Customer name — 0007 Tully, B. 15/01 180
requires data to be 0008 Hughes, D. 25/01 60
collected about customer

Monthly sales —
requires collection
of sales data

FIGURE 5.3 From reports to inputs

CHAPTER 5 Systems development 209

 Once the inputs have been clarified, the next step is to design the storage mechanism, with this typically
leading to database design and the generation of entity-relationship diagrams (or object-oriented database
designs), discussed in chapters 3 and 4. Documenting the analysis of inputs to a system can also be useful
for understanding what inputs are prepared, how they are used and where they end up. The inputs that are
going to be entered into the system must be considered for how the accuracy of them will be tested. It is
important to ensure that your input is validated and accurate. This can help identify any redundant docu-
ments. Clarke provides, as a basis for this analysis, a form identification sheet, which would be used to
record the different input forms within a system.14 An example is provided in figure 5.4.15

FORM IDENTIFICATION SHEET

Prepared by:
Date:

Form name: __________________________________ Form number: __________________________________

Purpose of form:

Form generated by: (describe event and person)

Form used by: (describe role in process)

Frequency of form use: >daily / Daily / Weekly / Monthly / <once a month

Period form is retained for:

Storage location:

Time from generation to storage:

Controls over form: (e.g. is it prenumbered . . .)

FIGURE 5.4 Form identification sheet

Logical design
As mentioned, the logical design describes how the new system will operate. Based on the information
gathered as part of the requirements analysis, a system will be designed that incorporates the features or
alterations that were identified as important to users. This could include changes in the operation of the
system as well as changes in the business processes that interact with the system. A key part of the log-
ical design phase is to arrive at a model of how the new system should operate. Some of the techniques
that are used in doing this include the mapping of business processes that are mentioned in chapter 2.

210 PART 2 Systems characteristics and considerations

 The business process map can be used to illustrate any changes in activities or functions as a result
of the new system design, as well as clarifying how the system will interact with others involved in a
business process. Similarly, data flow diagrams (both logical and physical) can be used to show how
the different data flows will be handled by the new system. Note that these documents are technology
independent, that is, they do not specify the technology that will be used in the new system. This is the
key feature of the logical design: it specifies what the system will do, not how it will do it. What pro-
cessing occurs needs to be considered in light of internal controls as well. For instance, if all the inputs
to the system are to be validated for accuracy, what processes are going to occur within the system to do
this and how can we ensure the accuracy of these processes? For example, how can we put in checks to
ensure the correct customer account has been increased by the correct amount?
The preparation of mapping business processes for the new system can also be useful in gaining an
understanding of how the new system is different from the old. Particularly with regard to the logical
activities that occur within a business process, preparing logical data flow diagrams for the new and
existing system and comparing them can be a useful way of understanding what changes have been
made and how the new design addresses the requirements identified as part of the analysis stage of the
systems development project.16 Internal controls are needed to be designed into the system at this point
and the auditor of the system needs to be involved at this point.
Another part of the logical design can involve the conceptual design of any databases that may exist within
the system. This will involve the preparation of entity-relationship diagrams (or object-oriented database
diagrams such as Universal Modelling Language database designs), which is discussed in chapters 3 and 4.
Again, however, note that these diagrams show what the database design will be and not the actual technical
aspects of the database. That is, they represent a logical perspective of the system, not a physical perspective.
Technical design
Once the logical design is arrived at, the challenge for the designers is to find the technology that can
allow for the successful implementation of the logical design. This can include specifying the nature of
the hardware and technical resources that are required for the system to successfully operate (e.g. server
capabilities, network requirements, telecommunications transfer rates and so on). The technical design
also involves consideration of the user interface, which is what the users see and work with on the com-
puter screen. There are various options for the design of this, with the key principle being user friendli-
ness. The area of design concerned with the user interface is referred to as human computer interaction
because it is through the interface that the user interacts with the computer.
Design approval
As the design phase is now complete, in addition to having the designer’s superiors sign off, it is also
essential to obtain user approval before progressing further. All user input and output screens and printed
report designs should be approved and signed off by user management, internal auditors and preferably
also by the actual users of these items as their more intimate knowledge may pick up otherwise unrecog-
nised changes. A prototype could be developed at this point to assist users in envisaging how the screens
will look and how the system will operate (prototypes are discussed later in this chapter). It is imperative
that designers and users concur that this design meets all requirements as at this stage the cost in both
time and money of making any changes is far less than it will be later on in the project life cycle. Once
the design has been signed off, no further design changes should be permitted as continual change and
rework will inevitably cause significant cost increases and delays to the entire project. Any proposed
changes can be incorporated as maintenance tasks after implementation.
Selecting vendors
Once the design of the new system has been finalised, the organisation must determine from where
it is going to source the required hardware and software. One alternative that may be pursued is the
tendering of the implementation to an outside organisation. This is initiated through a request for pro-
posal (RFP). This is a document outlining the specifications for the new system, which is sent out to

CHAPTER 5 Systems development 211

potential vendors. The RFP provides vendors with details about the company, the current system and the
problem that they are addressing by undergoing the systems development. It will then proceed to detail
the requirements of the new system and the general design of the new system. The typical contents of an
RFP are contained in figure 5.5. A possible way of laying out an RFP is shown in figure 5.6.17

1. Description of the organisation

(a) Operations
(b) Current system
(c) Problems with the current system
2. Outline
(a) Timeline for project
(b) Proposal requirements
(c) Cost responsibility
3. Requirements for the new system
(a) Hardware
      i. Requirements
    ii. Features
   iii. Criteria
(b) Software
      i. Requirements
    ii. Features
   iii. Criteria
(c) Service and maintenance
   i. Requirements
4. Conclusion
The intention is for the vendors to return the document with a tender containing details of how they are
able to meet the different design specifications contained in the RFP. The organisation will then rank the
tenders and select the one that best meets its criteria. In selecting the vendor from those who reply to the
RFP, the organisation will consider several different factors. These are discussed in AIS Focus 5.2.

FIGURE 5.5 Contents of the RFP

Recommended system (name and description)

How many of your clients currently use this system?
Yes/no Quantity Explanation/comments
Is the processor part of one of the terminals?
Can terminals be read (polled) remotely by using telephone lines?
Can terminals be read from remote terminals?
Can terminals be programmed from remote terminals?
Can the system use PCs to poll transactional data?
Do you supply the PC?
Can you recommend what brand and model of PC to purchase?
How many cash drawers can be connected to one terminal?
To which accounting system does your system interface?
Can your system be connected to a credit-card chip reader?
Does your system have the ability to enter and store daily sales forecasts?
Does your system compare forecasted numbers with actual counts during
each period?

FIGURE 5.6 A sample layout of an RFP for a restaurant considering a new sales system
Note: The respondent would fill in the details and return the document to the organisation.

212 PART 2 Systems characteristics and considerations

 AIS FOCUS 5.2

Selecting a vendor based on RFPs

Kasavana and Smith David (1992) detail nine steps for selecting vendors.18 These steps are summarised
as follows.
1. Assign responsibility: someone needs to be in charge of managing the selection process. This can
include coordinating the timeline for the project and initiating the investigation and analysis phases.
2. Describe your needs: in the simplest terms, describe what you expect the system to do. This involves
understanding the business process in question, how it operates and the different input and output
documents that are a part of the system.
3. Prepare the RFP: convert identified needs into an RFP. This should tell potential vendors about the
organisation, its aims, what it wants now and what it expects in the future. Standardised response
formats can greatly assist in comparing different vendor responses.
4. Rank RFP replies: criteria used for ranking replies from vendors are typically multidimensional,
and include ability to meet specifications, the reputation of the vendor, the financial costs involved
and the usability of the proposed solution, among other factors. The organisation needs to deter-
mine the important factors and the weights for each factor. This leads to a weighted score for
each proposal.
5. Demonstrations from approved vendors: a shortlist of vendors who have replied, based on their
weighted scores, will be invited to demonstrate their product. This can involve coming on-site and
responding to scenarios that are context specific, for example, showing how the product meets
requirements such as performance, ability to handle unique firm transactions and ability to meet the
firm’s unique needs. This is essentially an elaboration, in person, of what the vendor specified in its
RFP reply.
6. Presentation evaluations: evaluate vendor presentations and shortlist a group of acceptable
presentations.
7. Second round vendor visits: for the second group of shortlisted vendors, visit their sites and deal
with any concerns that may be lingering from stage 5.
8. View clients of shortlisted vendors: see how other clients of the shortlisted vendors have found the
vendor. Ask about service quality, reliability, quality of product and so on. Don’t just follow the cus-
tomer list the vendor gives you — ask around for yourself and find out what those clients have to say
about the vendor.
9. Select a vendor: negotiate the terms of the agreement and begin the process of implementation.

The steering committee is also involved at the end of the design phase ensuring that all the design
sign-offs have occurred relating to the design from the users, designers, designers’ superiors and man-
agement. The steering committee also gives final approval relating to the vendor that has been chosen by
the design team from the requests for proposals. Once final approval is given the project will continue to
the implementation phase.

Implementation
The implementation stage of the systems development life cycle involves getting the system up and run-
ning within the organisation. This requires the activities of building the physical environment required
for the new system to operate in (e.g. the network infrastructure) as well as the data storage facilities
(databases). When building the databases, the logical schema developed through the entity-relationship
diagrams will be the basis for the physical implementation. Any required programming must also be
completed, with this involving both writing and testing code before its implementation. If the system
does not require the preparation of source code, with the system instead being already developed, that
system must also be installed and tested. The auditor also needs to be involved in the testing of the
internal controls that were designed in the design phase. After these installation activities, thorough
testing will occur and the conversion plan for switching from the old system to the new system will be
prepared and executed. After this, the critical issue of user training will be tackled.

CHAPTER 5 Systems development 213

Network and database
If the new system requires the installation of new network or database facilities, they will be the starting
point of the implementation phase. The technical specifics for the network and database come from the
specifications that were developed in the analysis and design stages. This implementation stage rep-
resents the flow-through from the logical design to a set of specifications to a physical implementation of
the network and database. Many of the tasks at this stage will be performed by technicians and network
administrators. If an external vendor has been selected through an RFP process, then it may handle this
stage of the implementation. Further discussion of the technical intricacies of this stage is beyond the
scope of this text.
Programs
The programs for the new system can come in two forms: existing programs requiring modification
(customisation) or in-house-developed programs. Depending on the options chosen, the tasks required
will vary.
Modified existing programs
Most existing systems in organisations were designed for a wide range of users with no specific organ-
isational context in mind, while some others were designed for a specific user and then generalised for
sale to a wider market. A way around the problem of the system not meeting specific user needs of
the adopting organisation is to redesign the modules of the program and customise them to meet these
needs. This can be done by arrangement with the vendor of the program. While offering the benefit of
a well-developed product that is customised to meet individual needs, this approach introduces several
risks, which should be evaluated seriously. These include the possibility of introducing bugs as the code
is altered, the reluctance of the vendor to support the product once it has been modified and the potential
extra costs involved in modification.
In recent years, as organisations increasingly turned towards ERP systems as a way of better man-
aging their organisations, the issue of customisation has been topical. Theoretically, ERP systems should
be adopted as they are, that is, off the shelf, because their design represents ‘best practice’, otherwise
known as the best way of doing things. However, there will be situations where the ERP system does
not match the strategy of the organisation. This can require the modification of the ERP system to meet
the organisation’s unique aspects. In theory this makes sense, but the reality is that it can significantly
increase the cost and risk of ERP implementation within an organisation. When upgrading the ERP
product many of the customisations will be lost.
In-house-developed programs
Programming is the conversion of system processes that were specified in the design phase into instruc-
tions that the computer can understand and execute. The development and coding of in-house-developed
programs requires the involvement of programmers and other technical specialists in coming up with a
set of code that meets the requirements of the organisation. Often, the programming completed at this
stage will be based on a simple prototype that was developed as part of the design phase. Prototyping is
discussed in more detail later in this chapter. Issues for programmers to consider when developing pro-
grams include how well the program will interact with any existing systems, as well as the reliability
of the program: does it do what it is meant to do and with minimal error? Considerable effort will be
devoted as part of the programming stage to debugging and testing. Testing will be planned and docu-
mented on a test plan, with any exception outcomes noted and subject to investigation.19 At the lowest
level, there is stub level testing, then unit level and, lastly, system level testing.20
Testing at the stub level involves looking at the different components of a program and making sure
that they each function properly. In the example of an accounting program, it may involve looking at the
cash receipts, cash payments, accounts receivable, accounts payable, and sales and inventory modules
individually, ensuring that they function as expected.
When moving to testing at the unit level, the concern becomes how the different modules work when
combined. Again, using the accounting program example, the concern would be how well the cash

214 PART 2 Systems characteristics and considerations

receipts, cash payments, accounts receivable, accounts payable, and sales and inventory modules work
together. For example, when a sale is recorded in the sales module, are the accounts receivable and
inventory modules updated correctly? When cash is received from debtors, do the data entered into the
cash receipts module help the updating of records by the accounts receivable module?
At the highest level is system testing, which is concerned with how the developed program inte-
grates with any existing programs. Again, with reference to the accounting program, there may be
interest in the newly developed accounting system’s ability to share data with pre-existing pro-
grams related to manufacturing and warehousing. This stage of system testing will involve a range
of stakeholders, including designers, users and auditors. The sample data that are used as a part of
the testing phase may also be incorrect, for example, a customer number that is meant to be numeric
(e.g. 312968) may be entered in an alphanumeric form (e.g. C31296). Entering incorrect data and
ensuring that the system detects the errors are just as important as ensuring that correct inputs are
handled properly.
To test a system, a ‘test deck’ of transactions is created, including all possible errors and invalid
transactions. Testing should be done by users working with the development team rather than solely
by developers. The expected results from processing this group of transactions are calculated manually.
The test results are compared with the expected results and, if there are discrepancies, the cause of
the error is found and corrected. Testing is cyclic: test, compare, correct and test again until no further
errors are found. The test deck should be kept for reuse, for example, for any subsequent modification
to the system.
Testing
The final stage of testing will be aimed at making sure the new and the old systems are able to operate
with the same results. At this stage of testing, a set of sample data may be input into the system to ensure
that it is processed and stored correctly and accurate outputs are generated. This stage of testing can be
described as full system testing with test data and will involve operators inputting test data, with atten-
tion paid to how well operators are able to correctly use the system. Finally, testing with live data may
occur. This will involve taking existing data that has been processed by the old system and running it
through the new system. This will allow for a comparison of the outputs from the old and new systems.
In this situation, if the results differ and no errors can be located in the new system, it may pay to check
that the old system is working correctly. It is not unknown for this process to uncover that the old system
had been making unnoticed errors for years!
Implementation approaches
There are three implementation approaches that an organisation may consider when switching over from
its old to its new system: direct, parallel and phased-in conversion.
As the name would suggest, the direct conversion method involves switching off the old system
today and switching on the new system tomorrow. It is an immediate switch from the old to the new.
This can have the advantage of lower implementation costs, when compared with the parallel approach,
if the new system functions as expected. However, the direct approach can also expose the business to
several risks. One example is that, if there is a problem with the new system that has gone undetected
until the switch-over and it causes the new system to fail, then the organisation is left without an infor-
mation system. Therefore, having a backup plan of being able to switch back to the old system is recom-
mended if, after a certain period of time (e.g. 24 hours), the new system fails to operate.
Parallel conversion involves running the new system and the old system together for a period of
time, that is, operating them in parallel. This overcomes the risk of the direct switch-over previously dis-
cussed: the impact of a problem with the new system on the organisation is kept to a minimum because
the old system is still operating. Of course, the downside of the parallel approach is that for some time
the two systems need to be kept running, which can add to costs. Also, in many cases this may not be
practicable. For example, if checkout terminals in a supermarket are connected to the new system, they
cannot physically also send data to the old system.

CHAPTER 5 Systems development 215

 The phased-in conversion involves a gradual implementation of the system throughout the organ-
isation. Under this approach, the new system will be introduced in a small part of the organisation and
gradually phased in throughout the entire organisation. This is, in a sense, a compromise between the
direct and parallel methods because it allows the system to be implemented and operational while at the
same time reducing exposure should it fail. This approach is practical if there are separate business units;
for example, a state branch office may be selected as the pilot for the rest of the organisation. There is
an additional safeguard here as the organisation can have a ‘plan B’ whereby, if the new system fails, the
pilot branch’s data may be processed in another state branch until the problems are rectified.
Preparation for conversion
There are two other main issues for an organisation to consider in preparing for the conversion of the old
to the new system: the preparation of the users of the system and reviewing the system documentation,
ensuring that users are able to follow the documentation and procedures correctly.
Users
Preparing the users to use the new system has consistently been identified in information systems research
as one of the critical factors in the success of projects. The users adopting the new system are critical to the
new system achieving its intended objectives. Organisational facets such as structure, management style and
change approaches can be important in this area.21 To this end, organisations can pursue various strategies to
improve the prospects of user acceptance. User involvement in systems development is an important way of
giving users a sense of control.22 Historically, many within an organisation have been resistant to the intro-
duction of new technology in the workplace because it represents a threat to the way things have been done in
the past and they may feel that their jobs are threatened. A new system also challenges worker competency:
a user who is proficient with the existing system may suddenly be faced with the prospect of not knowing
how to use the new system. This can be damaging to the individual’s self-esteem. A way around this is to give
users the perception that they are actively involved in the determination of the implementation schedules. A
way of doing this is by providing users with an instrumental voice, which is the chance for them to have their
say and express their concerns.23 This will occur before decisions are made. For example, in the implemen­
tation stage, rather than management mandating training courses across a range of areas, an instrumental
voice would suggest the need for employees to suggest courses that may be relevant for them to improve their
skills in using the new system.
As part of user training in the way the new system operates, Wastell suggests the use of transitional
objects.24 As Wastell observes:
ISD [Information systems development] is a process of organizational change in which IT systems
are designed and deployed to enable more effective operational practices. To bring this about, the pre-
vailing business paradigm must be questioned with goals, processes and roles considered in the light of
new technological potentialities. Both IS professionals and users must engage in an intensive learning
experience, the former to develop a thorough understanding of the business domain, the latter to reflect
on current practices and to acquire an understanding of the potential of IT to transform how work
is done. Through this process of communication and discovery, design work is progressively accom-
plished, ultimately resulting (if all goes well) in a technically sound system that satisfies the users and
meets the business requirement  .  .  .  an effective learning process is thus critical to the success of ISD.25
The role of users in the systems development process, with their function as both learners and possessors
of knowledge, is critical to the success of the development efforts.26 Users of the system possess a great deal
of knowledge about how the existing system operates, including its problems and strengths. This knowledge
is vital to improving a system and can be gained from users early on in the systems development process,
typically as a part of the investigation and analysis stages of the systems development life cycle. This is the
main reason that accountants and internal auditors need to be involved at this stage of the life cycle, and high-
lights the importance of them understanding why different information is being requested from them.
Once systems are complete and ready for implementation, users may have to be retrained in the use of the
new system. Users are learners in this process, seeing how the new system operates and being introduced to

216 PART 2 Systems characteristics and considerations

new features, processes and support material. The people who could fill the role of trainer include system
designers or analysts who possess a deep knowledge of the systems design and operations, professional
in-house trainers or, where the system is purchased from a third-party vendor, the vendor’s own training staff.
This latter option is common in organisations adopting ERP systems, with vendors such as Oracle offering
education programs for management, end-users and project teams implementing an ERP system.27
Focusing on the end-user group, Oracle sees the benefits of its end-user training programs as follows:
‘With the right set of skills, you can give  .  .  .  [end-users] the confidence, knowledge, and competency to
achieve long-term success. As a result, you’ll see faster acceptance of the solution and new application-
related processes, and you’ll be able to establish a higher level of capability and performance. Put
simply — the more skilled your end-users, the more value you’ll get from your PeopleSoft [Oracle]
solution’.28 Another leader in the ERP market, SAP, has developed a tutorial and simulation environment
to assist in the training of end-users.29
The impact on the user of having to learn a new system should not be underestimated, making the
role of change agents and project leaders critical in getting and maintaining support for the system. It
should also be recognised that training has to be targeted to the needs of the different users. Not all users
need to know how all of the system works: training all users in all aspects of the system wastes time and
ignores the typical distribution of responsibilities within the organisation. Therefore, a training program
for different groups (e.g. sales, accounting and purchasing) at different times is important. The goal of
training is for end-users to have the skills to perform their jobs. They do not have to know the working
of the system in intimate detail.30
Documentation
The importance of mapping business processes was introduced in chapter 2, where the role of data flow
diagrams and systems flowcharts in providing a graphical representation of a system’s operation was
discussed. These documentation formats play an important role in systems development, representing
invaluable planning and design tools at the various stages of the systems development life cycle. Other
forms of documentation are also important. The internal controls chapters (chapters 8 and 9) discuss the
role that job descriptions can play in outlining individual responsibilities and accountabilities within the
organisation. Some of these may alter as a result of the systems development effort in conjunction with
the internal auditor’s input, which makes it important for organisations to review existing documentation
in light of the new system, identifying any changes that may have been missed and ensuring that the
revised documentation captures them.
Other important pieces of documentation at this juncture of the development life cycle are user
manuals and support materials. User documentation may come in various formats (e.g. paper-based,
online or on CD). It must be usable, understandable and accurate, enabling users to follow the material.
It is critical that documentation is developed progressively during the development of the system and
not left until the end. All too often developers move on to other jobs inside or outside the organisation
before documentation is completed and there is no-one who really understands the inner workings of the
system available to prepare and finalise documentation.

Maintenance and review

Once the system is implemented and operating smoothly and users are trained in its operation, the main
tasks of the development team become those of maintenance and review. The maintenance and review
activity can be a significant part of the cost of system development (up to 80 per cent). Naturally, when
there are changes in maintenance activities, the internal auditor or accountant needs to be involved to
ensure adequate internal controls have been redesigned into the improvement or modification.
The maintenance phase has the general aim of keeping the new system running and supporting users in
their interactions with the system. This helps contribute to the end goal of enabling the system to reach the
benefits identified in the investigation and analysis stages of the system’s development. Typical maintenance
activities that will be required are system improvements, system modifications and bug correction.31

CHAPTER 5 Systems development 217

 System improvement activity involves adding new features or functions to the system, thus increasing
its potential usefulness. Ideas for system improvements may emerge as users operate the new system in
day-to-day operations and identify small points that could be added or modified to improve the usability
of the system. An example of system enhancement could include adding a new function to a menu.
System modification is, as the name suggests, a change to the system. Rather than adding to the
existing features, as is the case with system improvement, it takes an existing feature and alters it. An
example of a potential reason for system modification is the introduction of a new law that affects the
operation of the organisation (e.g. a requirement to collect a new tax, such as GST).
The final type of maintenance is bug correction, which involves fixing any errors in the system. These
errors are the result of programming mistakes and are more of a threat when organisations develop their own
system in-house or attempt to customise an existing package. A critical part of the maintenance task is to log
any problems that occur with the system, enabling the appropriate people to be informed so the problems can
be fixed. Therefore, a log should be available to record any bugs that users encounter while using the system.
The log may be generated electronically — for example, as a program experiences an error condition, an
error is automatically logged to an electronic file that technical staff periodically review or an audit alarm bell
is activated — or manually recorded by users as they encounter bugs in their daily duties.
If the scope of the improvement, modification or correction is large, the maintenance effort may pro-
vide the trigger for a new systems development project to be launched. This emphasises the iterative
nature of the systems development life cycle: development is an ongoing feature within the organisation
and does not stop once the system is implemented and the development team has signed off.
Whether the maintenance task is adequately performed relies on the maintenance team being aware
of the problems or issues confronting users of the system. To this end, a maintenance system that gains
user feedback and provides a forum for users to log their requests or problems is essential. Traditionally,
this would have been carried out through the use of a maintenance request form. These requests will be
logged in a maintenance request log, maintained by the IT department. Many organisations now have
online facilities where users can log their requests through a web page. This also allows the tracking of
the requests by users.
The review stage completes the systems development life cycle and is concerned with carrying out
an ex-post analysis of how well the systems development project has worked. Aspects that may be
considered as part of the review can include the project team’s performance and the new system’s per-
formance. When reviewing the performance of the project team, factors such as good performers, bad
performers and the relevant skills contributed by team members may be considered, as well as ability to
meet deadlines. The review should not be conducted immediately after implementation, but should allow
for a suitable settling down period for users to become familiar and comfortable with the new system
and for any teething troubleshooting to be completed.
System review is concerned with how well the new system is performing. In carrying out the system
review, the initial costs and benefits developed at the early stages of the systems development life cycle
should be referred to, with these providing the rubric for evaluating how well the new system has met
expectations.
In the next section we discuss the different methodologies for systems development. Most of the
methods are based around the systems development life cycle but amended to try to remove some of the
criticisms of the traditional life cycle.

5.3 Alternative systems development approaches

LEARNING OBJECTIVE 5.3 Compare and contrast alternative approaches to systems development.
While there are many benefits from following the steps of the traditional systems development life cycle
due to its structured, well-controlled and well-documented approach to systems development, there are a
number of alternatives to the traditional systems development life cycle. These methods are usually used
in certain circumstances, and they do employ aspects of the traditional method.

218 PART 2 Systems characteristics and considerations

 However, as mentioned in the section earlier, some of the aspects of the traditional systems devel-
opment life cycle may not be useful, and the alternative approaches discussed below try to counter
the issues with the traditional method. These methods are summarised below in figure 5.7. Only some
methods are shown here as organisations often develop their own systems methodology by incorporating
aspects of other methodologies.
The first method in figure 5.7 is the traditional systems development life cycle, which passes through
the phases of the life cycle as discussed above. Under the traditional methods you cannot start the next
phase until the last phase is complete. The adaptive systems development method, the second method in
figure 5.7, allows phases to overlap. The third method, iterative systems development, uses the systems
development life cycle, but instead of using one cycle to complete a whole project, parts of the project
are broken down into iterations of the systems development life cycle. Thus you create different parts
of the system in each iteration. In this method, the first iteration of the systems development life cycle
includes much more investigation and analysis than the later cycles.
Movement from the traditional method to the adaptive method, which allows overlap, has occurred
because in the adaptive system one phase can start before another is finished. The move to the iterative
systems method means a project need not be taken on in one cycle, but can be broken down to deliver
parts of the system after the first cycle is complete. This counters the issue with the traditional system of
the cycles taking too long.
The next phase, prototyping, is discussed below.

Agile methods

Traditional systems Adaptive systems Iterative systems Prototyping Unified XP (Extreme Scrum
development life cycle development method development method Process (UP) programming)

FIGURE 5.7 Types of systems development methodologies

Prototyping
The systems development life cycle represents a very structured and methodical way of undertaking
development projects. However, it is often criticised for its lack of user involvement. Potentially, users
are only involved in the early stages and late stages of the life cycle, with little scope for user involve-
ment during mid-stages, such as design. This has led to support for the prototyping approach to systems
development. This actively involves the users in the development of the system by continually seeking
their feedback on and evaluation of progressive designs for the system.
The prototyping approach centres on the concept of building models and allowing users to experi-
ence these models and provide feedback on their operation and suitability. This can be advantageous in
situations where the users know what they want but are unable to clearly communicate it to designers,
or where users think they know what they want but are not sure. Providing feedback on the design and
features allows the prototype to be altered to meet users’ needs. The revised prototype will then be pre-
sented to users for further evaluation and feedback. The prototyping process is described as an iterative
process: the model of the system goes back and forth between user and designer until an agreed version
is arrived at.
Prototyping can be used as a stand-alone systems development technique but can also be used in
conjunction with the stages of the systems development life cycle previously described. The advantage
of prototyping is that it allows the users to be involved in a more hands-on manner with the systems
development efforts and can help to achieve a usable and accepted system when implementation occurs.
Users can interact with the prototypes, make changes to the system according to what they need from the
system and see from the prototypes what the end product will be.
Prototyping is an ideal approach where the systems development effort is small and focused on a key
group of users.

CHAPTER 5 Systems development 219

Agile/adaptive methods
Agile/adaptive methods involve short team-based efforts whereby a small amount of functionality is built,
designed and tested at a time. These methods aim to reduce the risks of the long systems development life
cycle by using shorter, smaller steps. The overall project, as it is attempted in small pieces, may be fluid
to changes in requirements. This is because the process between the developer and the user of the system
continues as the system is developed. Iterative, spiral cycles over time build up the system. An overall
scope, objective and original requirements, as determined in a traditional systems development life cycle
investigation phase, are never determined under these methods. As a result, the project can never be meas-
ured against these elements. This is considered an area of risk. However, a positive of these development
methods is that, if the needs of the organisation change, the agile methods are able to adapt and respond to
user feedback. Therefore, the changing needs of the organisation may be able to be accommodated with
these methods. Agile methods promote an ‘agile manifesto’ that lists the principles that are followed by
these methods. This manifesto is contained in figure 5.8. Unified Process (UP), XP (Extreme program-
ming) and Scrum are all methods that follow the agile approach but are slightly different in their execution.

Principles behind the agile manifesto

We follow these principles.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
• Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity — the art of maximising the amount of work not done — is essential.
• The best architectures, requirements, and designs emerge from self-organising teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.32

FIGURE 5.8 Principles behind agile approaches to systems development

There are a variety of other methods that use concepts from these alternative methods to ensure
that developers develop what users require, including extreme programming, scrum, joint application
methods and rapid application development. These methods are not detailed in this book; however, the
further reading section of this chapter contains useful references for them. While alternative system
development methods focus on ensuring that users get the system they require, the disadvantages
include a lack of linkage between what is being achieved at the team level and an overall vision of the
system development. As a result, the traditional systems development life cycle has survived over time
as the most popular method for systems development. The COSO and COBIT frameworks outlined
in chapter 8 recommend structured systems analysis using the systems development life cycle with a
clearly set out scope and requirements. However, agile/adaptive methods are gaining popularity, par-
ticularly as they enable changes when priorities within an organisation change. Many of these methods
incorporate aspects of the systems development life cycle.

220 PART 2 Systems characteristics and considerations

5.4 Software selection for SMEs
LEARNING OBJECTIVE 5.4 Describe the software development options available to smaller businesses and
demonstrate how this knowledge can be used to outline the systems selection processes for decision making.
While the reasons for acquiring new accounting software for small to medium-sized enterprises (SMEs) are
as described in the introduction to this chapter, and are the same as for larger enterprises, the software will
almost certainly be a pre-developed program and the selection process is therefore usually simpler.

Pre-developed programs
Using pre-developed programs means that the business is adopting a package that already exists: the code
has already been written and the program is typically ready to run. An example of this approach is pur-
chasing a program such as Microsoft Word or the Xero accounting package. The program will typically
be provided on a set of CDs or DVDs, or in a downloadable file that can be purchased from the software
vendor online, with these files needing to be installed on the user’s machine. Once the installation pro-
cess is complete, the software is ready to be used. Acquiring software through this approach can provide
several advantages for an organisation; the major advantage is avoiding the costs of programming and
development. The organisation also receives a well-developed and hopefully error-free product. For fairly
mainstream requirements, such as word-processing applications or simple accounting packages, using
pre-developed programs makes economic sense. It is important for both simple and mid-range accounting
systems that the built-in internal controls are evaluated by the organisation’s accountant or auditor.

Types of accounting packages

We will examine the key features of two levels of accounting software here — mid-range and simple
systems. We will also introduce software-as-a-service providers — companies that provide software
applications that can be leased to customers.
Mid-range accounting packages
Mid-range accounting packages may be purchased direct from the developer or a value-added reseller; for
example, a CPA firm or consultant who provides installation assistance, training and ongoing support. These
packages are usually developed as a series of interlocking modules including most or all of the following
features: general ledger, sales, point-of-sale, receivables, inventory, purchases, payables, payroll and a report
writer. It is generally possible to purchase only those single modules actually required by the nature of the
business. Mid-range systems also have the benefit of a flexible chart of accounts, which facilitates producing
reports for the consolidated entire organisation, by state or store, or alternatively by product groups.
Most systems are built on top of sophisticated database software, such as SQL. Users are normally
able to access the database directly, to answer ad hoc queries or perform unique analyses, and are able to
produce reports not already coded by the software.
Mid-range products provide a large number of optional ‘switches’, enabling users to select from a
broad range of options for each feature, and can accommodate a large number of simultaneous users
depending on the licence purchased.
Simple accounting packages
Simpler accounting packages may be purchased direct from the developer or an office supplies or big
box retailer. They are normally purchased ‘as is’, without modifications or unique features. Such simple
packages usually carry a relatively inflexible chart of available accounts, compared to mid-range modules,
and users are generally unable to directly access the underlying database to conduct more unique pro-
cesses. Compared to mid-range packages, users are generally restricted to fewer options for each feature,
and such programs generally operate at a capacity of around five simultaneous users. Generic accounting
packages of this nature are significantly cheaper, with the entire package similar to the cost of a single
module in a mid-range product.

CHAPTER 5 Systems development 221

Software as a service
Service providers (SPs) can also be used as they are a means for businesses to acquire access to a system
or program through an independent provider. The programs are typically delivered through web-based
means and offer benefits through economies of scale and lower upfront investment. Issues to consider
with SPs are reliability, the level of service and the strategic nature of any data or processes connected
with the service provider. This is discussed further in chapter 6 in the cloud computing section.

5.5 Typical problems of systems development

LEARNING OBJECTIVE 5.5 Recognise typical systems development problems and propose solutions for
their resolution.
Systems development projects can present organisations with myriad challenges and issues that must be
dealt with for the project to have any chance of being successfully completed. Many of these centre on
the areas of cost, scope and time.33 Some problems include the great potential for conflict, escalation of
commitment, project goal issues, technical skills, interpersonal skills and a lack of scope. Each of these
is now briefly discussed, highlighting how they inhibit the success of systems development projects.

Conflict
Conflict is disagreement between individuals, groups or organisations. While conflict is widely viewed
as positive for an organisation because it promotes diversity of opinion and open discussion of ideas,
it can also have devastating effects on the organisation. The systems development process, by virtue of
it uniting a wide range of stakeholders, is an environment that is ripe for conflict. Users often feel that
designers are not listening to their requests, while designers think users do not know what they want and
can never be satisfied.34 These two stakeholders, users and designers, approach the systems development
project from very different perspectives, with one often not totally understanding the other. Jealousy and
hostility can result.

Escalation of commitment
Escalation of commitment has been extensively researched in the management accounting area and
refers to an increased level of commitment towards a project that has previously been chosen and that
is not progressing as expected and that should be abandoned or redirected.35 In systems development
projects, the reality is that very few will be completed on time, even less on time and under cost, and
some just will not be completed at all because they were doomed to fail from the start. Despite such
poor outcomes, organisations may spend significant money on a systems development project that is not
progressing as planned, in the desperate hope of righting the wrongs of the past and getting the project
back on track. The reality is that this is like rearranging the deckchairs on the Titanic.
The question that needs to be answered is why does such commitment allow the continued support
of what would appear to be doomed projects? Keil et al. suggest several theories for why this escalation
occurs, including self-justification theory, prospect theory and agency theory.36
Self-justification theory states that a person makes a decision to justify a previous decision and to save
face. For example, rather than terminate a systems development project that is over budget, off schedule
and destined for failure, the theory posits that the manager will invest more resources in the project in
the hope of turning it around. This behaviour is particularly prevalent where the manager was involved
in the earlier decision to go ahead with the project.
Prospect theory explains escalation of commitment through the way a decision to proceed or ter-
minate a project is framed for the decision maker. It works on the premise that people will be willing
to take a risk if the outcome is guaranteed to be negative. In the case of systems development, this
can be seen as the definite loss of the initial investment if the decision to withdraw from the project

222 PART 2 Systems characteristics and considerations

immediately is made versus the possible larger loss or success that could eventuate from continuing
with the project. This explains the idea of throwing ‘good money after bad’ and ignoring sunk costs: a
management accounting term for costs that have already been incurred and are irrelevant to the decision
to proceed with the project.
Agency theory refers to the problem of the person in charge of the systems development project having
an information asymmetry over the higher levels within the organisation. Because of the technical nature of
many systems development efforts, it is possible for those involved to make statements about progress that
are difficult for others to prove or disprove. This is especially the case for programmers and other technical
specialists, whose technically specific knowledge places them in an almost unmonitorable position. In such
a situation, because individuals are motivated by self-interest, the inclination is to protect one’s own repu-
tation and position. As such, people may be reluctant to report bad news about the progress of the project,
so the firm continues to support a project that is not progressing as expected. Another example of the agency
problem in systems development is the inability to monitor those who work in technically specific areas. For
example, if you are in charge of supervising a project and have no programming experience, how do you
monitor the performance and progress of the programmers? Without the requisite knowledge and skills such
monitoring becomes problematic. Many tasks that require specific skills and are highly specialised may exist
in a systems development project, making the monitoring of progress difficult.

Project goal issues

Typical problems with project goals can include goals that do not have the universal support of those involved
and goals that are too broad in scope. The systems development effort needs to occur within the boundaries
of what the system is required to do, its goals and objectives, and the importance of the system within the
organisation. Having a clear concept of the boundaries of the scope of the project is important when it is first
conceived, as well as during its progression through its various stages.37 The goals of the systems develop-
ment project will ultimately drive the information requirements that are fulfilled in the development stages.
Consequently, a project that is not clear on what it is meant to achieve may deal with the wrong issues and
lack consensus on what the real issues to be dealt with should be. This becomes an issue for the systems
steering committee which is required to sign off on the scope, analysis and requirements stages of the project.

Technical skills
The systems development project requires a mix of technical, people and process skills. Process skills
refer to knowledge of how the business operates, what is done and who does it. People skills refer to
the ability to manage different groups of people, assimilate differences of opinion and manage conflict
towards a workable solution that benefits the project as a whole (conflict was discussed in an earlier
section as an aspect of systems development). Technical skills refer to the ability to perform the tasks
required in developing and implementing the system within the organisation. Organisations undergoing
systems development need to assess the capabilities that they have within the organisation. There may be
instances where the proposed systems development is beyond the skills and expertise of the staff within
the organisation, in which case they should look towards help from outside the organisation, such as
consultants or those with the relevant expertise. Acknowledging a deficiency in skills and rectifying it
early can be important in the progress of a systems development project.
As an example, an IT department that has previous experience in maintaining a business’s systems is
probably not adequately skilled to run a systems development effort, because other required skills such
as interacting with different stakeholders to determine user requirements, project management skills and
so on will most probably not be present.

Interpersonal skills
Interpersonal skills are essential in any systems development effort. These skills come to the forefront as
systems development efforts can involve people from a wide range of backgrounds and levels throughout

CHAPTER 5 Systems development 223

an organisation working together on the one project. The perspective of the IT personnel or the pro-
grammer may be very different from that of the end-user of the system. This makes an ability to work
with others, acknowledge different viewpoints and collaborate towards the attainment of a mutually
acceptable solution important.

5.6 Systems development management tools

LEARNING OBJECTIVE 5.6 Critique and describe some common systems development tools.
Many tools can be used in managing the systems development project within an organisation. An aware-
ness of these tools is important. Many failed information systems development projects are identified as
such because the project ran out of control, both financially and time-wise. Tools that assist in the plan-
ning and control of systems development projects force those involved to have a thorough understanding
of the steps involved in completing the project and can provide a basis for accountability in systems
development projects, while also providing structure and an overall picture for larger projects. Some of
the commonly mentioned tools are Gantt charts and critical path analysis/PERT charts for project plan-
ning and controlling, and critical path analysis/PERT charts and computer-aided software engineering
(CASE) systems for analysis and design.

Gantt charts
A Gantt chart is a graphical way of planning and controlling the progress of a systems development pro-
ject. The Gantt chart depicts the timeframe for the project along the x-axis and the activities that are part
of the project along the y-axis. Horizontal bars for each activity depict how long it is planned to take and
how long it actually has taken. As figure 5.9 shows, the Gantt chart identifies the major activities that
occur within a project and the timeframe for each activity. In the figure, the investigation activity took
less time than expected, while the analysis activity took longer than expected. The overall project was
completed after the budgeted completion date.

Investigation

Analysis

Design

Implementation

Maintenance
and review

5 10 15 20 25 30 35 40 45
Time (days)
Budgeted time
Actual time

FIGURE 5.9 A Gantt chart

224 PART 2 Systems characteristics and considerations

 The level of detail in the Gantt chart is up to the preparer: the chart could equally have looked at
activities within the investigation stage or the analysis stage. The degree of detail is determined by user
needs. However, one thing to note about the chart is that it does not identify dependencies between
activities; that is, we do not know how the different activities in our chart relate to and affect each other in
very much detail. This is overcome through the preparation of a PERT chart/critical path analysis. PERT
charts are beyond the scope of this text and are covered in any introductory project management course.

CASE
CASE systems are software packages that can help in the various stages of systems development, but particu-
larly in the design of source code and user documentation. McNurlin and Sprague (1998) describe CASE soft-
ware as consisting of, among other things, a planning facility and a code generator.38 The planning facility is
where the designs, such as entity-relationship diagrams, are specified. These allow for the identification of the
relationships among different parts of the software that is being developed. The code generator will then gen-
erate code based on the specifications and requirements that have been entered. The CASE tools are designed
to support those developing systems, offering help in generating the necessary code and supporting the pro-
duction of user documentation. A detailed discussion of CASE technology is beyond the scope of this text.

SUMMARY
5.1 Exhibit judgement in explaining how business size and complexity may influence the
choice of systems development strategy for an organisation.
Choosing an accounting system is not a one-size-fits-all exercise. Organisations may be classified by
their size and turnover, with corresponding accounting packages varying in sophistication, but a larger
entity may still find that a simple package fulfils all its needs, while a smaller business may be able to
justify the expense of a complex ERP system due to the unique features of their operations. In most
cases, however, the complex, time-consuming and expensive process of evaluating the need for an ERP
is unnecessary for SMEs, and a simpler methodology may be followed in this case.
5.2 Summarise the stages of the systems development life cycle and critically evaluate the
importance of organisational strategy as the basis for systems development.
There are five stages to the systems development life cycle: investigation, analysis, design, implementation and,
finally, maintenance and review. Investigation is aimed at identifying any problems with the current system.
Analysis develops potential solutions to the identified problems and evaluates them based on their feasibility.
The design stage prepares a logical and physical design for the newly proposed system and culminates in the
preparation of a returned vendor proposal (RFP). The RFP is assessed by the organisation and a final vendor
selected. This leads to the implementation stage, which relies heavily on the role of user training and education.
Implementation can occur using a direct, parallel or phased approach. Once implemented, a system will be
monitored for any errors or problems in its operations, as well as being improved with new features.
Organisational strategy needs to be the basis for evaluating systems development project ideas. A
system that does not meet an organisation’s strategic priorities can distract it from doing the things it
does best and will weaken the distinctive nature of the organisation. The notion of organisational fit
between what the system does and what the organisation aims to do is important.
5.3 Compare and contrast alternative approaches to systems development.
Prototyping is a development approach that makes strong use of users in evaluating models of the pro-
posed system. This allows for a user-friendly system and for high consultation between user and designer,
helping reduce potential resistance to a system once it is introduced. Object-oriented analysis methods
are generally used when object-oriented systems are being developed. Agile/adaptive methods use small
spiral cycles to develop systems; users and developers work in conjunction under these approaches.
Alternative approaches lack overall systems objectives and outputs against which the new system can be
measured, but are gaining popularity due to their flexibility.

CHAPTER 5 Systems development 225

5.4 Describe the software development options available to smaller businesses and
demonstrate how this knowledge can be used to outline the systems selection processes
for decision making.
SMEs usually work with pre-developed programs, rather than undertaking to develop and test a unique
product in-house. Pre-developed accounting packages come in two forms — mid-range packages, which
are modular and allow a reasonably significant number of options for each feature, and simple packages,
which allow fewer options but are much cheaper. Organisations looking to change their software systems
should consider the following selection process: identify the company’s needs, survey the market,
identify a shortlist, arrange a demonstration, and decide and implement.
5.5 Recognise typical systems development problems and propose solutions for their resolution.
Typical problems encountered in systems development projects include the potential for conflict when
stakeholders from different perspectives try to agree on what is needed. The problem of escalation of
commitment can emerge once a project has commenced, which can lead to good money being thrown
after bad. Project goal issues can also emerge, largely as a result of poorly defined goals, goals that lack
support from those involved or goals that lack clarity and scope in their definition. The range of tech-
nical skills and interpersonal skills required to successfully complete a systems development project can
also present many challenges for an organisation.
5.6 Critique and describe some common systems development tools.
Common systems development tools include Gantt charts, PERT charts and CASE tools. Gantt charts
and PERT charts provide graphical techniques for monitoring the progress of a project and for sched-
uling activities that need to occur. CASE tools provide computerised tools that assist in activities such as
code generation and systems documentation.

KEY TERMS
Agile/adaptive method An alternative approach to systems development that involves short, team-
based efforts whereby a small amount of functionality is built, designed and tested.
Bug correction Involves fixing any errors in the system as a result of programming mistakes.
Computer-aided software engineering (CASE) systems Software packages that can help in the various
stages of systems development, but particularly in the design of source code and user documentation.
Direct conversion Involves switching off an old system and immediately switching on a new system.
Feasibility analysis Involves the evaluation of the alternatives identified to determine whether they are
legitimate options for the business to consider at later stages of the development.
Financial feasibility Assessment of the costs involved in adopting a new system, systematically
compared with the financial benefits of a new system.
Gantt chart A graphical way of planning and controlling the progress of a systems development project.
Legal feasibility How the proposed system would operate given the legal environment faced by the
organisation.
Logical perspective An approach that is concerned with a design that is independent of the actual
technology required for its implementation.
Organisational fit How well the technology is aligned with the overall organisational strategy and
strategic priorities.
Parallel conversion Involves running the new system and the old system together for a period of time,
or operating them in parallel.
Phased-in conversion Involves a gradual implementation of the system throughout the organisation.
Physical perspective Requires specification of the technical aspects of how a design will be achieved.
Programmed evaluation review technique (PERT) chart A chart constructed through the
identification of all the activities that must take place for the project to be successfully completed,
with time allocations given to each activity and activities sequenced based on necessary prerequisite
and subsequent activities.

226 PART 2 Systems characteristics and considerations

Prototyping approach Involves the progressive building of models, allowing users to experience these
models and provide feedback on their operation and suitability.
Request for proposal (RFP) A document outlining the specifications for the new system, which is
sent out to potential vendors.
Schedule feasibility The ability of the proposed solution to be implemented within the period of time
that is specified by the organisation.
Strategic feasibility How well the proposed systems development alternative fits in with the
organisation’s existing operating environment and strategy.
System improvement Involves adding new features or functions to the system, thus increasing its
potential usefulness.
System modification Involves taking an existing feature and altering or changing it.
Systems development scope Defining what problems the systems development project will cover.
Systems development steering committee Responsible for determining whether the systems development
project should proceed; members typically occupy positions of power throughout the organisation.
Technical feasibility The assessment of how well the organisation’s existing technology infrastructure
meets the requirements of the proposed alternative.
Total cost of ownership The need to consider not just the initial costs of installing a system but also
the ongoing costs following the implementation of a system.

DISCUSSION QUESTIONS
5.1 Explain the relationship between strategy and systems development. (LO1)
5.2 Describe the key activities that occur in the investigation stage of the systems
development life cycle. (LO2)
5.3 Describe the key activities that occur in the analysis stage of the systems development
life cycle. (LO2)
5.4 Describe the key activities that occur in the design stage of the systems development
life cycle. (LO2)
5.5 Describe the key activities that occur in the implementation stage of the systems
development life cycle. (LO2)
5.6 Describe the key activities that occur in the maintenance stage of the systems
development life cycle. (LO2)
5.7 Discuss the advantages and disadvantages of a phased-in and direct switchover
implementation strategy. (LO2)
5.8 What is the role of the steering committee in a systems development project? (LO2)
5.9 What is the role of a feasibility analysis within systems development projects? (LO2)
5.10 Describe each type of feasibility that is considered as part of a feasibility analysis. (LO2)
5.11 Critically evaluate how much end-users are actively involved in the systems
development life cycle approach to systems development. (LO2)
5.12 Describe alternative methods to the systems development life cycle. (LO3)
5.13 Critically evaluate the usefulness of prototyping as a systems development approach. (LO3)
5.14 Summarise the five typical problems associated with systems development. (LO5)
5.15 For each of the typical systems development problems identified in the chapter,
suggest a solution that could potentially overcome the problem. (LO5)
5.16 Describe how a PERT chart and a Gantt chart can be used to manage and control
systems development projects. (LO6)
5.17 Critically evaluate the usefulness of Gantt and PERT charts in managing systems
development projects. (LO6)
5.18 Describe how CASE tools can be used to manage and control systems development
projects. (LO6)

CHAPTER 5 Systems development 227

SELF-TEST ACTIVITIES
5.1 The systems development life cycle commences with the stage of: (LO2)
(a) implementation.
(b) investigation.
(c) analysis.
(d) design.
5.2 The RFP: (LO2)
(a) details the requests of users to be included in the system.
(b) lists the requirements identified in the requirements investigation stage.
(c) details requirements for potential vendors to follow.
(d) offers guidance about the existing systems operations and the required changes.
5.3 Prototyping has the advantage of: (LO3)
(a) providing a structured development process.
(b) providing thorough documentation.
(c) strongly involving users in the development process.
(d) ensuring users and technicians agree on design features.
5.4 SPs are an attractive option because: (LO4)
(a) all SPs are reliable.
(b) businesses avoid having to invest large amounts in applications.
(c) they give the organisation control over application development.
(d) they provide applications that service the business’s specific requirements.
5.5 Which of the following is not a level of testing? (LO2)
(a) Stub level testing
(b) Unit level testing
(c) System level testing
(d) Enterprise level testing
Answer the following questions based on the Gantt chart contained in figure 5.10. (LO6)

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

4 8 12 16 20 24 28 32 36
Time (weeks)
Budgeted time
Actual time

FIGURE 5.10 Gantt chart

228 PART 2 Systems characteristics and considerations

5.6 After the completion of activity 3, the project is progressing: (LO6)
(a) ahead of schedule.
(b) behind schedule.
(c) on schedule.
(d) cannot be determined based on information available.
5.7 Activity 2 was completed: (LO6)
(a) on time.
(b) ahead of time.
(c) behind time.
(d) cannot be determined from the information available.
5.8 The time taken to complete activity 2: (LO6)
(a) was more than expected.
(b) was less than expected.
(c) was as expected.
(d) cannot be determined from the information available.

PROBLEMS
5.1 Bina Memories is a small family photography business. The business has a good reputation for
high-quality photos and enjoys long-standing arrangements with many schools for the provision
of school photos. Bina Memories has traditionally used a small accounting package to manage
its operations, with Make Your Business Profitable ‘MYBP’ being the package currently in use.
Recently, however, a few of the staff in the administration team have complained that MYBP
has become slow in processing transactions. The computer that runs the program is also fast
approaching its capacity, having not been updated for several years and now also handling some of
the business’s digital imaging requirements.
As a result of the strained system, Bina Memories is considering the possibility of an upgrade.
However, it is concerned that, should it go ahead with an upgrade, it would have to employ a
programmer to develop its new system, as well as a full-time IT specialist to keep the system
running. It is also unsure of what needs to be done in managing the systems development
process.
One of the things particularly troubling Mr Cotton, the part owner of Bina Memories, is the
possibility of investing capital now and having to do so again in a couple of years’ time as
technology changes. However, he does not mind spending a large sum now if the system is a long-
term answer, since, as Cotton himself said, ‘Once the system is acquired then the business can get
back to normal and do what it does best — take photos — without having to spend money on IT.’
In light of the details you have about Bina Memories, prepare a discussion in relation to the
following questions.
(a) How correct is Cotton’s statement: ‘Once the system is acquired then the business
can get back to normal and do what it does best — take photos — without having to
spend money on IT’? Explain your reasoning. (LO2)
(b) Explain how it may not be necessary for Bina Memories to employ a programmer to
design a new system. (LO4)
(c) How could Bina Memories limit the costs of maintaining the system once it is in
place within the organisation? (LO4)
(d) Identify the key user requirements that would need to be fulfilled by the new system. (LO2)
(e) Would you recommend that Bina Memories make or buy the new system? (LO4)
(f) Describe the process that Bina Memories could use for selecting a vendor for the
new system. (LO4)

CHAPTER 5 Systems development 229

 (g) What are some of the possible consequences for Bina Memories of relying on a
single vendor for the system? (LO4)
(h) What typical systems development problems may Bina Memories face in developing
the new system? Suggest strategies for each potential problem. (LO5)
5.2 A software development project has been identified as having six stages, these being
(i) design the logical plan for the software operation, (ii) select a programming language,
(iii) write source code, (iv) test the source code, (v) integrate software with existing
applications, and (vi) train users. The time estimates for each of these activities are
contained in table 5.2, as well as actual time taken (where available, since the project is
only partly complete). (LO2)

TABLE 5.2 Project activities, budgeted time and actual time

Activity Budgeted time (days) Actual time (days)

Design the logical plan for the software operation 8 7

Select a programming language 2 2

Write source code 15 25

Test the source code 24 Not available

Integrate software with existing applications 4 Not available

Train users 7 Not available

Required
(a) Using the data in the table, construct a Gantt chart. (LO6)
(b) Comment on the ability of the project to meet its schedule: if all remaining activities
are completed according to budgeted times, will the project be completed on time? (LO6)
(c) What activities are over schedule? (LO6)
(d) Recognising that you are under pressure to meet the budgeted deadline for this
software implementation, since it forms a part of an organisation-wide strategic
initiative that will propel the company into the future, your boss suggests that you may
want to revise your plans for testing and training, to ensure that the original 60-day
schedule is met. One suggestion is to cut back on testing at the unit and system level
and just focus on testing at the stub level. What is your response to this suggestion? Is it
a good idea? Why? In your response be sure to distinguish between the different levels
of testing and the aims of each level of testing. (LO6)
5.3 Read AIS Focus 5.1 and answer the following questions.
(a) Explain why you think supermarkets moved towards self-serve checkouts. Specifically,
do you think it was an opportunity or a means of resolving problems with the current
systems? Justify your answer. (LO2)
(b) The article mentions two stakeholder groups involved in the introduction of the new
system. (LO2)
    (i) Identify each group.
  (ii) Suggest some of the issues that each group may have raised throughout their involvement
in the systems development.
(iii) Identify the stage of the systems development life cycle where each concern may
have been raised.
(c) Identify the risks that moving to the new system of self-serve checkouts may present
for supermarkets. (LO2)
(d) Evaluate whether or not the LCD trolley is likely to succeed for an average
supermarket. Justify your conclusion. (LO2)

230 PART 2 Systems characteristics and considerations

 (e) Identify and describe some of the cost–benefit factors that would be considered when
evaluating the LCD-equipped trolleys. (LO2)
(f) Suggest some of the strategies and techniques that the supermarkets would have
employed when implementing the self-serve checkouts in stores, as well as the groups
at whom these techniques would have been aimed. (LO2)
(g) Evaluate the proposed LCD-equipped trolleys using the applicable dimensions of
feasibility for: (LO2)
    (i) A large supermarket chain.
  (ii) A small independent grocery store.
(iii) Overall, do you think they represent feasible options? Explain your reasoning.
(h) Suggest reasons that some stakeholders may object to the introduction of the LCD-
equipped trolley system. (LO2)
(i) Evaluate the extent to which (a) the self-checkout system and (b) the LCD-equipped
trolley fit with the organisational strategy of your typical supermarket store. (LO2)
(j) Identify stakeholder groups that could be negatively affected by these technologies and
explain how they could be negatively affected. (LO2)
(k) Identify and describe two issues that the supermarket would have considered when
deciding to proceed with the self-checkout system. (LO2)
(l) From your own experience in shopping centres, do you think self-checkout systems
improve the shopping experience? Explain your answer using examples. (LO2)
(m) Suggest ways that the introduction of these new systems could impact on the
traditional sales process employed within a shopping centre. (LO2)
(n) Identify and briefly describe two ethical issues that may need to be addressed in
adopting both of these systems. (LO2)
5.4 AIS Focus 5.3 describes the Australian government’s move towards the introduction of an
integrated national medical health record system. It highlights some issues across the stages of
system development that have been covered in this chapter.
(a) Identify the stages of system development that are evident in this case and provide
examples of these stages from the case materials. (LO2)
(b) Identify the dimensions of feasibility that are present in this case. Describe how each
dimension of feasibility relates to the case material. (LO2)
(c) Explain why user adoption could be seen as critical to the success of the case. (LO2)
(d) Suggest and justify some strategies that could be employed to help with the
successful adoption of the system.
(e) An argument in the case concerned whether patients should opt-in or opt-out of
the system. Present an argument for whether you think the system should be opt-in
or opt-out. (LO2)
(f) The federal government allocated $467 million for the initial rollout of the system. Suggest
various means for funding the ongoing operation of the system, beyond the initial rollout, and
evaluate the likely success and consequences of the different funding options. (LO2)
(g) The system is expected to be rolled out by mid-2012. Describe the activities that
would be undertaken following the expected completion date. (LO2)
(h) Suggest some measures that could be used to evaluate the performance of the new
e-health system. Explain how each measure relates to system performance. (LO2)
(i) A feature of the system is the patient’s ability to select what data is made available
in the e-health system. (LO2)
(i) Do you agree with this feature? Explain your answer.
(ii) Suggest reasons that this feature was included.
(iii) Suggest reasons that this feature may not be liked by some parties.

CHAPTER 5 Systems development 231

 (j) Suggest reasons doctors may be reluctant to adopt the e-health system. Propose
strategies that could overcome these reasons. (LO2)
(k) Identify the benefits that the integrated e-health system could provide. For each benefit specify:
(i) what the benefit is
(ii) who receives the benefit
(iii) whether the benefit is financial or non-financial
(iv) the ability to measure the benefit. (LO2)
(l) Identify the likely major cost categories across the life of this system development.
For each cost category specify:
  (i) why the cost is necessary (e.g. advertising is necessary to create awareness about the system)
(ii) who would bear the cost. (LO2)
(m) Based on the discussion in the case, do you believe this system development passes
cost–benefit criteria? Explain your answer. (LO2)
(n) Suggest reasons the systems development described above, for a government body,
may be different to that followed by a smaller company or private business. (LO2)
(o) The system designers decided on a new 16-digit identifier for patients and providers.
  (i) Identify the stages of system development where this would have been
considered. Explain the likely discussion at each stage.
(ii) Suggest some of the issues that may have been raised in deciding on the creation
of the new 16-digit identifier. (LO2)
(p) Describe the process that the government should follow in deciding where to source
the software to support this system. (LO2)
(q) Suggest some areas that would need to be examined when testing:
  (i) how the system operates within individual clinics (LO2)
(ii) how the federal government’s central system interacts with individual providers and users.
(r) Suggest and justify a conversion strategy that might be followed by a local clinic that
is linking up to the system. (LO2)

AIS FOCUS 5.3

An integrated medical record system

In 2009, the Australian government embarked on a journey towards the creation of a Personally Con-
trolled Electronic Health Record System that would see a patient’s medical records accessible online
to practitioners, patients and other relevant parties, with patients also able to make comments on their
records.39 The new system has now been implemented and the government sent consultation reports
to Australian citizens in July 2015.
Australia faces an increasing population and — within that growth — an increasingly ageing popu-
lation, and the demands on the health system have been predicted to double over the coming dec-
ades.40 For the health system to function into the future, it is critical that new operational efficiencies
are found. Following the lead of such countries as Denmark and the United States,41 the introduction
of the Personally Controlled Electronic Health Record System formed part of a review of the health
system by the National Health and Hospitals Reform Commission.42 The e-health system will see the
medical records of Australians stored electronically and made accessible through a network that con-
sists of patients, practitioners and other relevant parties. It is envisaged that the system will offer ‘secure
and timely access to information about  .  .  .  current medications, diagnoses, allergies, immunisations
and  .  .  .  health treatment preferences’.43
The argument for the e-health system was that it would reduce costs and add efficiency to the health
system. Reported estimates of the cost savings potentially available from moving the health records
online were in the vicinity of $8 billion over a decade.44 Additionally, the new system was seen as
a means of preventing around 5000 deaths per year.45 Examinations of the current system of health
record management highlighted the potential to reduce the duplication and fragmentation that existed,
as well as the potential to afford a higher quality of service to patients being treated.46 Duplication

232 PART 2 Systems characteristics and considerations

occurs, for instance, when a patient visits one doctor and then is referred to another or seeks a second
opinion (where details of allergies and medications need to be recaptured, as well as prior test results
and immunisation status for various diseases), not to mention the additional records that are created
when a patient enters hospital or is treated in an emergency admission. At present, if a patient is
admitted to emergency after hours their existing records may be held in a clinic that is not open, pre-
senting potential challenges for the medical staff on duty treating the admission.47 While most general
practitioners have moved to the electronic age, with computerised prescriptions, health records and
scheduling, it was noted that the ‘situation in our hospitals is not so good. The likelihood that some of
the data stored in your GP’s computer can be transmitted to the hospital or a specialist, or vice versa,
is close to zero’.48 The initiative would also seem to work towards doctors having relevant information at
hand when seeing new patients for the first time, with these doctors also able to access this information
in a timelier manner.49
The Federal Health Minister at the time, Nicola Roxon, also saw the move as a means of reducing
the potential for mismatched information about patients. Given the large amount of information that
flows between general practitioners, public hospitals, private hospitals and other healthcare pro-
viders, the importance of linking the right information to the right patient cannot be understated.50
One dares not think of the consequences of mismatching results for one patient’s tests to another
patient’s records. Add to that the potential for medication errors, unnecessary procedures being
carried out and duplicated tests51 and you have examples of wasted resources within the health
system, as well as an obvious cause of inconvenience, discomfort and stress for the patient. The
Minister also pointed out the above benefit of avoiding both the duplication of patient tests and
medication errors.52
The e-health system consists of several parts, one of which is the Personally Controlled Electronic
Health Record System. Legislation was passed by the Parliament in June 2010 providing the authority
for the government to proceed with the scheme and issue healthcare identifier numbers to all Austral-
ians.53 The healthcare numbers, discussed below, represent a critical first step in the operation of the
system, with their creation reflecting a step towards the recommendation from the National Health and
Hospitals Reform Commission, which specifically stated:
We recommend that, by 2012, every Australian should be able to:
• have a personal electronic health record that will at all times be owned and controlled by that person;
• approve designated health care providers and carers to have authorised access to some or all of their
personal electronic health record; and
• choose their personal electronic health record provider.54

In order for Australians to have their own unique personal health record that they control, it is
necessary for the system to be able to distinguish between and identify each Australian. To achieve this,
the healthcare identifier number was created. This unique 16-digit identifier is an example of a primary
key and it is used to identify patients and healthcare providers within the e-health system. For patients,
this number is linked to their Medicare card.55 This identifier will be linked to data about the individual —
name, address and date of birth56 — and will be used to link the government’s database to that of
healthcare providers. Health records from visits to general practitioners, pathologists, specialists and
chemists will be stored in other secure locations, along with prescriptions and referrals and encrypted
links between doctors and hospitals.57 Such links could be used for the communication of test results
and x-rays in a secure manner without the risk of them being lost in transit.58 These would be linked to
the government’s central database through the client identifier. The decision for this structure was based
on the government’s belief that the government does not require ‘a central database storing every piece
of information’.59
The individual healthcare identifier system that houses and manages the individual healthcare infor-
mation was developed by a third party for the government and is required to link up with the systems
that are used by healthcare providers. The individual healthcare identifier is key to this being achieved.
This means developers for the healthcare providers need to put in place systems that are able to com-
municate with the individual healthcare identifier system and send and receive data accurately and
securely. It will also require the systems to access the individual healthcare identifier database for cus-
tomer biographic details and a process for verification of provider and patient identifiers.

(continued)

CHAPTER 5 Systems development 233

 AIS FOCUS 5.3 (continued)

In designing the system, the consideration of privacy was obviously of paramount importance. Media
reports indicated that the e-health system would fall under the coverage of Australia’s privacy laws,60
with Roxon commenting that, amongst other measures, the system would update a log each time a per-
son’s record was accessed and that penalties of up to $66  000 for unauthorised access would apply.61
A further reflection of this concern for privacy was that it would be up to the patient to decide whether
or not they wished their records to be included in the system,62 with it operating on an opt-in basis. In
addition, patients would be able to access their records and determine what details were viewable by
other parties. In emergency cases, hospitals might be permitted to search the patient’s records.63
The opt-in basis of the system has been criticised by the Australian Medical Association, which believes
that an opt-out approach is preferable in order to attain as large as possible coverage by the system.64 The
Australian Medical Association’s concerns particularly centre on the new system missing those who are
not technologically aware or those who are unable to access technology (e.g. nursing home patients, the
elderly — who possibly do not access technology, or those who are unaware of the system’s operation).
Similar health systems have been introduced overseas, with Auckland introducing an opt-out based system
that reportedly had only a small number of patients exit the system,65 with this seen as an indication that the
chances of a mass exodus were low if an opt-out approach was to be employed. The United States is also
reported to be introducing a similar program for the health industry, encouraging investment by healthcare
providers in the necessary technology to support an electronic health record system.66
Arguments for an opt-out based system go to the core idea of how a network offers value — the more
participants involved, the greater the benefit that it potentially offers. For example, a phone system where
only two people have telephones is of limited benefit to the community, but as more people join the benefits
increase through the broader communication permutations and accessibility that follow. A similar argument
applies with the e-health system: for the benefits to be attained, as many users as possible — patients, doc-
tors, specialists, chemists, pathologists etc. — need to embrace the system. Failure to reach a critical mass
of participants could mean that, while some aspects of the health system may be electronically operated,
others may remain in the traditional fragmented operating procedures of the past.
Concerns about getting a critical mass of participants have not been isolated to the discussion of
patients opting in. Similar sentiments have also been expressed about healthcare providers opting in,
with these concerns being voiced by those within the domain of the healthcare profession. Drawing on
the NSW experience, where an electronic system was initiated, then NSW Health Minister Jillian Skinner
commented that ‘If you don’t engage the clinicians who have to use the system then you’re in dire
straits  .  .  .  [NSW] rolled FirstNet out without proper clinical engagement, without the proper investment
in training, software and equipment’,67 with the state’s system being blamed by doctors for service out-
ages, as well as reportedly having excessive technical complications.68
Lessons from overseas experiences with online health have also pointed towards the importance of data
standards for sending and receiving data, as well as security of data and ensuring that the different systems
are able to communicate with each other. Given that a distributed approach appears to be the preferred
method for implementing the system in Australia, such connectivity becomes a crucial design issue. The
experience in Denmark, where an e-health project was launched, was that this can take up to ten years to
get right.69 Morten Elbæk Petersen, managing director of Denmark’s e-health portal, is reported to have
commended the way Australia took time to develop standards that could be built on in the future.70
In order to fund the system, the federal government committed $467 million to the first two years of the sys-
tem’s introduction.71 Beyond this, there seems to be uncertainty as to how the funding will be sourced, with
an alternative being that the system will fall under the ongoing federal health budget. Media commentators72
have posited that this presents some interesting questions about future funding alternatives. For example:
• Should the government continue to fund the system beyond its initial two-year commitment?
• Since patients choose to be a part of the system, should they have to pay an annual fee?
• If patients do have to pay an annual fee, what is the appropriate amount? Should such an amount be
scaled, based on income?
• Since doctors and healthcare professionals are using information from the system, should doctors,
pathologists, specialists and chemists have to pay a subscription fee?
Other financial issues have also been flagged — including the cost of training doctors and health
practitioners in the operation of the system, as well as ensuring that they have the appropriate facilities
for storing data and accessing the health network.73

234 PART 2 Systems characteristics and considerations

 During discussions about the system there have been some concerns about the fact that people
have had health identifier numbers generated without their knowledge. Concern has also been
expressed about the use of the system beyond the health dimension, with the flagging of fears about
the scope creep of the system and it being used to build potential links, for example, to government
welfare data.
Future areas for development are also in need of consideration, such as how it can be expanded
to potentially include social media and other avenues to broaden the application and benefit that it
provides to the delivery of healthcare in Australia. This, no doubt, will be a consideration for future
projects.
In 2013, former Federal Health Minister Peter Dutton announced a review of the $1 billion Personally
Controlled E-Health Record System owing to its failure to attract doctors to participate. There has also
been very little interest from the public to sign up, including via the website portal set up for this pur-
pose. In 2013, there were 900 000 patients signed up, with only a few hundred healthcare providers
putting up the ‘shared health summary’ that lists all the patient’s details and around 5000 documents
uploaded in total.74 Commentary has suggested that the e-health records system is not easy to use.
The interface between the doctors’ software and the PCEHR is difficult, and uploading the shared health
summary needs to be done line by line with the patient, which is seen to be inefficient. The review of the
system will assess what users were expecting from the system against what has been delivered. It will
also look at the level of consultation during the development of the system and the use of the records,
including barriers to uptake, usability issues, what needs to be done to fix the system and the potential
for the private sector to provide solutions to fix the system.
A review of the Personally Controlled Electronic Health Records in 2014 found significant challenges
with the opt-in system and a lack of focus on those who need the e-health record the most. In its
Budget 2015, the government announced a trial of the opt-out system, which would see all Australians
having an electronic health record, with the option to opt out of the system if they wished. New legis-
lation has also been proposed that will assist in the control of a patient’s record.75

FURTHER READING
Hawryszkiewycz, I 2001, Systems analysis and design, 4th edn, Prentice Hall, Upper Saddle River, NJ.
Kendall, KE & Kendall, JE 1999, Systems analysis and design, 4th edn, Prentice Hall, Upper Saddle
River, NJ.
Satzinger, JW, Jackson, RB & Burd, SD 2012, Systems analysis and design in a changing world,
6th edn, Cengage Learning, Boston, MA.
Shelly, GB & Rosenblatt, HJ 2010, Systems analysis and design, 8th edn, Cengage Learning, Boston, MA.
Rosenblatt, HJ 2014, Systems analysis and design, 10th edn, Cengage Learning, Boston, MA.
Valacich, JS, George, JF & Hoffer JA 2001, Essentials of systems analysis and design, Prentice Hall,
Upper Saddle River, NJ.

SELF-TEST ANSWERS
5.1 b, 5.2 c, 5.3 c, 5.4 b, 5.5 d, 5.6 b, 5.7 a, 5.8 b

ENDNOTES
1. Horswill, A 2008, ‘Self serve checkouts a new moral dilemma’, The Courier-Mail, 8 September, www.news.com.au.
2. Collier, K 2011, ‘As supermarkets go high-tech, shoppers want checkout chicks’, The Herald Sun, 21 January, www.news.com.au.
3. Collier 2011.
4..Militec, D 2008, ‘A new way to shop — check it out for yourself’, The Age, 22 April, www.theage.com.au.
5. Horswill 2008.

CHAPTER 5 Systems development 235

 6. Changarathil, V 2011, ‘Smart trolleys set for SA debut’, The Advertiser, 16 July, www.adelaidenow.com.au.
7. Collier 2011.
8. Compaq n.d., ‘TCO models and approaches’, www.hp.com.
9. Compaq n.d.
10. Hawryszkiewycz, I 2001, Introduction to systems analysis and design, Pearson Education Australia, Sydney.
11. De Michelis, G, Dubois, E, Jarke, M, Matthes, F, Mylopoulos, J, Schmidt, JW, Woo, C & Yu, E 1998, ‘A three-faceted view of
information systems’, Communications of the ACM, vol. 41, no. 12, pp. 64–70.
12. Donzelli, P & Bresciani, P 2004, ‘Improving requirements engineering by quality modelling — a quality based requirements
engineering framework’, Journal of Research and Practice in Information Technology, vol. 36, no. 4, pp. 277–94.
13. Donzelli & Bresciani 2004.
14. Clarke, RT & Associates 1987, Systems life cycle guide, Prentice Hall, Englewood Cliffs, NJ.
15. Based on Clarke, RT & Associates 1987.
16. Hawryszkiewycz 2001.
17. Kasavana, ML & Smith David, J 1992, ‘Scripted computer demonstrations — how to standardize vendor’s presentations’, The
Cornell HRA Quarterly, June, p. 78. Reproduced with permission.
18. Kasavana & Smith David 1992, pp. 75–83. Reproduced with permission.
19. Dennis, A & Wixom, BH 2000, Systems analysis and design — an applied approach, John Wiley & Sons Inc., New York.
20. Whitten, JL, Bentley, LD & Dittman, KC 2001, Systems analysis and design methods, 5th edn, international edn, McGraw-Hill
Higher Education, New York.
21. De Michelis et al. 1998.
22. Baronas, A-MK & Louis, MR 1988, ‘Restoring a sense of control during implementation: how user involvement leads to
system acceptance’, MIS Quarterly, vol. 12, no. 1, pp. 111–23.
23. Hunton, JE & Beeler, JD 1997, ‘Effects of user participation in systems development: a longitudinal field experiment’, MIS
Quarterly, vol. 21, no. 4, pp. 359–88.
24. Wastell, DG 1999, ‘Learning dysfunctions in information systems development: overcoming the social defenses with
transitional objects’, MIS Quarterly, vol. 23, no. 4, pp. 581–600.
25. Wastell 1999, p. 582.
26. Wastell 1999.
27. Oracle 2005, ‘Education services can help maximize the value of your Peoplesoft investment’, www.peoplesoft.com.
28. Oracle 2005.
29. SAP 2005, ‘SAP education: end user and performance solutions’, www.sap.com; SAP 2002, ‘Knowledge is power, knowledge
is productivity’, www.sap.com.
30. Dennis, A & Haley Wixom, B 2000, Systems analysis and design: an applied approach, John Wiley & Sons Inc., New York.
31. Clarke & Associates 1987.
32. Manifesto for agile software development 2001, ‘Principles behind the agile manifesto’, www.agilemanifesto.org.
33. Schwalbe, K 2002, ‘Chapter 1: Introduction to project management’, in Information technology project management, 2nd edn,
Course Technology, Cengage Learning, Boston, MA.
34. Barki, H & Hartwick, J 2001, ‘Interpersonal conflict and its management in information system development’, MIS Quarterly,
vol. 25, no. 2, pp. 195–228.
35. Keil, M, Mann, J & Rai, A 2000, ‘Why software projects escalate: an empirical analysis and test of four theoretical models’,
MIS Quarterly, vol. 24, no. 4, pp. 631–64.
36. Keil, et. al. 2000.
37. Schwalbe 2002.
38. McNurlin, BC & Sprague, RH 1998, Information systems management in practice, 4th edn, Prentice Hall, Upper Saddle River, NJ.
39. Department of Health and Ageing 2011, ‘Personally controlled electronic health records’, www.yourhealth.gov.au; Department
of Health and Ageing 2011, ‘E-health’, www.yourhealth.gov.au.
40. Coiera, E 2010, ‘The net can be good for your health’, The Sydney Morning Herald, 25 May, www.smh.com.au.
41. Coiera 2010.
42. National Health and Hospitals Reform Commission 2009, ‘A healthier future for all Australians — final report of the National
Health and Hospitals Reform Commission — June 2009’, Government of Australia, Canberra, ACT, www.health.gov.au.
43. Spriggs & Fry 2011.
44. AAP 2009, ‘Report recommends online health database’, The Age, 20 July, http://news.theage.com.au; Kissane, K 2010,
‘Health of a nation to go by the numbers’, The Age, 18 September, www.theage.com.au.
45. Drape, J 2010, ‘Aussies to get electronic health records’, The Age, 12 May, http://news.theage.com.au.
46. Drape, J 2011, ‘Electronic health records on track: Roxon’, The Age, 11 April, http://news.theage.com.au; O’Rourke, J 2011,
‘Online health records face uphill battle’, The Age, 7 August, www.theage.com.au.
47. Yeates, C 2009, ‘Electronic health records to save lives’, The Age, 28 July, www.theage.com.au; Coiera 2010.
48. Coiera 2010.
49. Yeates 2009.
50. AAP 2009.

236 PART 2 Systems characteristics and considerations

51. Coiera 2010.
52. Drape 2010.
53. AAP 2010, ‘E-health records closer to reality’, The Australian Financial Review, 25 June, www.afr.com.
54. National Health and Hospitals Reform Commission 2009.
55. Kissane, K 2010, ‘Health of a nation to go by the numbers’, The Age, 18 September, www.theage.com.au.
56. Drape 2011.
57. Kissane 2010.
58. Drape 2010.
59. Drape 2011.
60. AAP 2009, ‘Report recommends online health database’, The Age, 20 July, http://news.theage.com.au.
61. Roxon, N 2011, ‘Security of medical records assured’, The Australian Financial Review, 4 October, www.afr.com.
62. Kissane 2010.
63. Drape 2011.
64. O’Rourke 2011.
65. O’Rourke 2011.
66. Alonsi-Zaldivar, R 2010, ‘Ambitious timetable for electronic medical records’, The Age, 14 July, http://news.theage.com.au.
67. Ramli, D 2011, ‘Doctors’ support vital to e-health: Skinner’, The Australian Financial Review, 3 November, www.afr.com.
68. Ramli 2011.
69. Bajkowski, J 2010, ‘Reality check for online health’, The Australian Financial Review, 14 September, www.afr.com.
70. Bajkowski 2010.
71. Spriggs, M & Fry, C 2011, ‘Every detail of your ills at the touch of a button’, The Age, 15 April, www.theage.com.au.
72. Spriggs & Fry 2011.
73. Spriggs & Fry 2011.
74. Taylor J 2013, ‘Australia’s “struggling” e-health records under review’, 3 November, www.zdnet.com/article/
australias-struggling-e-health-records-under-review/.
75. Scott, S 2015, ‘Budget 2015: new “opt out” e-health system to see all Australians given e-health record’, ABC News, 10 May,
www.abc.net.au/news/2015-05-10/government-to-fund-ehealth-for-all-australians/6457940.

ACKNOWLEDGEMENTS
AIS Focus 5.2: © Sage Publications / Kasavana & David, Cornell Hotel and Restaurant Administration
Quarterly, June 1992, pp. 75–83, copyright 2012 by Sage Publications. Reprinted by permission of
Sage Publications.
Figure 5.8: © Agile Manifesto.
Photo: NAN728 / Shutterstock.com.

CHAPTER 5 Systems development 237

CHAPTER 6

Technology concepts
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

6.1 recommend why organisations are motivated to implement or upgrade enterprise resource planning
(ERP) systems
6.2 categorise the key business processes that ERP systems support
6.3 describe the main modules in an ERP system through using SAP as an example
6.4 explain how XBRL is used in reporting systems
6.5 compare and contrast the different ways XBRL can be used
6.6 justify the benefits of XBRL
6.7 analyse the various concepts in using XBRL
6.8 categorise the different types of Cloud-based computing including Software as a Service
6.9 analyse the concept of big data and how it is used.
Introduction
Different types of systems or technologies are used in organisations to capture transactions and produce
reports that are used for planning, decision making and reporting. Several of those systems have been
developed for different sized businesses, more or less complexity and different information needs. Sev­
eral modern systems/technologies are discussed in this chapter including enterprise resource planning
systems (ERP), eXtensible Business Reporting Language (XBRL), cloud computing and big data. At the
end of the chapter some systems/technologies that haven’t been discussed but may also affect accounting
information systems, such as social media, bring your own device (BYOD), robotics and wearable tech­
nology, are briefly described.
The chapter has four parts. In the first part ERP systems are outlined and their inherent character­
istics explained. These systems are one of the types of systems used by larger, more complex organ­
isations. An example of an ERP system — SAP (Systems Applications & Products in Data Processing),
a German product that makes major enterprise software packages — is described and illustrated.
The second part of the chapter covers eXtensible Business Reporting Language (XBRL) technology.
XBRL is a standard for the electronic communication of business and financial data, and it is revolution­
ising business reporting around the world. XBRL provides major benefits in the preparation, analysis
and communication of business information. It offers cost savings, greater efficiency, and improved
accuracy and reliability to all those involved in supplying or using financial data. XBRL is set to become
the standard for business reporting.
In the third part of the chapter cloud-based computing is discussed. Cloud-based computing uses
remote computing facilities owned by others to provide software, hardware and infrastructure to busi­
nesses. These services are accessed over the internet. This means that the individuals or businesses using
cloud-based computing services do not have to own the software, hardware or infrastructure that they
are using.

CHAPTER 6 Technology concepts 239

 Lastly, we look at big data. Big data relates to the types of data that are collected when you are
accessing social media, for example. When you access Facebook sites or use Twitter, this data is
recorded. Remember it’s not just your data but that of every other person using Facebook or Twitter. A
lot of data is generated from an individual’s use of social media. How this data is stored and then ana­
lysed is the question for big data analysts.
The chapter begins with a discussion of ERP systems.

6.1 Why an ERP system?

LEARNING OBJECTIVE 6.1 Recommend why organisations are motivated to implement or upgrade
enterprise resource planning (ERP) systems.
Many different types of software systems designed to support different functions within organisations
are available on the market and many of them have functions enabling them to span organisations. Soft­
ware systems automate business processes and link those business processes within an organisation and
between organisations.
Originally, accounting systems catered only for the accounting functions in the business and did not
address the needs of marketing or human resources. However, over time, these departments began to
want information from the accounting system. Sales wanted information on sales forecasts and com­
missions, and human resources wanted information on employees and payroll costs. As a result, hybrid
systems were developed which included accounting functions as well as modules for sales and human
resources.
ERP systems, on the other hand, grew from the needs of the manufacturing industry, which required
material requirements planning (MRP) software to enable plant managers to plan production and raw
materials requirements for each part of the manufacturing process based on sales forecast information
from the business’s sales department.
MRP software thus paved the way for the development of hybrid systems to be used in manufacturing.
The hybrid systems were a way to integrate the sales department, finance department and manufacturing
department through systems software. The main advantage of these systems was their ability to integrate
an organisation’s operations with its financial functions, unlike the earlier accounting systems that added
on additional modules but did not have the advantage of integrating the various departments in a busi­
ness. The MRP systems facilitated communication and decision making among operational and financial
divisions in an organisation. These MRP systems evolved over time into the fully integrated enterprise
information system that could holistically capture all of an organisation’s activities and transactions,
known as ERP.

6.2 Business processes supported by

ERP systems
LEARNING OBJECTIVE 6.2 Categorise the key business processes that ERP systems support.
ERP systems are designed to capture a wide range of information about all business transactions and
processes related to the typical four major areas in an organisation: sales and marketing, finance, manu­
facturing and human resources. These systems link the typical major functions of an organisation and the
organisation’s suppliers and customers in the value chain.
ERP systems link:
•• sales and marketing: the division of the organisation that sells the products and services
•• accounting and finance: the division of the organisation that manages the business’s financial assets
and maintains its financial records
•• manufacturing: the division of the organisation that purchases raw materials to be converted into
products and services that provide customer value

240 PART 2 Systems characteristics and considerations

•• human resources: the division of the organisation that attracts, develops and maintains the business’s
labour resources and employee records
•• suppliers: the businesses that provide direct and indirect raw materials to the manufacturing division
of the organisation
•• customers: the people who purchase products and services from the organisation because they value
those products and services.
Given these links in the system, this is the main reason why an ERP system is attractive to businesses.
As ERP systems can capture a wide range of information about all key business processes within an
organisation and share this information between its business processes and other organisations, this inte­
gration of all departments and functions in a business into one system means that redundant information
is not held by each department. The information is shared between the departments. Figure 6.1 shows
this integration and the interrelationships within the organisation.

Customer
Shipping
orders

Inventory
Equipment
management

Human
resources

Warehouse Manufacturing

A/R A/P Receiving Procurement

Financial system

Manufacturing/
Human Accounting Sales and
inventory
resources and finance marketing
management

FIGURE 6.1 ERP system functionality

CHAPTER 6 Technology concepts 241

 Figure 6.1 also shows that customer orders trigger the shipping area of a business. The shipping area
draws on inventory within the organisation, which in turn triggers manufacturing to produce further
stocks of products for inventory. Product manufacturing then forces the business to purchase and receive
raw materials from suppliers if required. At the same time, customer orders are recorded in the accounts
receivable area of the business, while purchases are recorded with accounts payable in the accounting
and finance division. To ensure that there is staff to perform the business processes and activities, human
resources manages salaries, wages and other functions across the organisation.
In summary, ERP systems support key business processes that involve the major functions in an
organisation. These processes include:
1. revenue, sales or order to cash
2. payments, purchases or purchase to pay
3. production, manufacturing or conversion
4. human resources and payroll
5. general ledger and financial reporting.
Each of these key business processes brings together different functions or divisions in the organ­
isation. For example, the revenue process brings together the sales and marketing department and
accounts receivable in the accounting department (which records the sales), while manufacturing (which
produces the product or service to sell) brings together human resources (which provides the sales,
finance and manufacturing staff for the revenue process to be executed).

6.3 ERP systems — SAP modules

LEARNING OBJECTIVE 6.3 Describe the main modules in an ERP system through using SAP as an
example.
There are many commercial ERP vendors, of which SAP is one. SAP’s products are suitable for large
organisations, and it is a dominant player in the ERP market. ‘SAP systems currently run: defence
systems in 107 countries, production of 75 per cent of the world’s beer, 65 per cent of the world’s choco­
late, 40 million barrels of oil and 32  000 car engines per day, and 50 million bank transactions per day.’1
Core modules of the SAP Business Suite ERP system are financial accounting (general ledger and finan­
cial reporting), controlling and profitability analysis (management accounting and decision making), human
resources (human resources management and payroll process) and sales and distribution (revenue process).
Going back to its origins, it also contains materials management, which includes production planning and
execution, quality management, warehouse management and plant management. The administration of the
system is in Basis Technology. Remember that it was originally a German product, therefore requiring trans­
lation into English of the administration module. The core modules will be updated in 2015 to S4 Hana.
The modules provide the necessary support for the five key business processes and functions in any
business. Most ERP systems contain similar modules and have similar functionality. The modules and
functionality mimic the key business processes that occur in reality in organisations. The key business
processes are discussed in chapters 10 to 12 of this text. The modules are briefly explained below.

Financial accounting (FI)

The financial accounting module is connected to all of the other ERP system modules and processes the mon­
etary transactions in the ERP system. The financial accounting system collects all the transactional data to
enable it to prepare the balance sheet, income statement and statement of cash flows for statutory reporting.
The financial accounting module maintains customer and vendor balances through fully integrated
accounts receivable and accounts payable sub-modules. Other sub-modules are included in this module,
with fixed assets being the most utilised. Performance reports for internal decision making are generated
in the controlling and profitability analysis module. Figure 6.2 provides an example of the sub-modules
in the financial accounting module.

242 PART 2 Systems characteristics and considerations

 FIGURE 6.2 Sub-modules in the SAP financial accounting module
Source: SAP.

Controlling and profitability analysis (CO)

The controlling and profitability analysis module, as it is termed in SAP, is the management
accounting module in the product. This module is designed to collect the data that provides the foun­
dation for preparing internal reports that support decision making in the organisation. The reports are
cost centre performance, profit centre performance and budget analysis, which are all the reports used
in a business’s internal performance reporting and relate to effective cost and revenue controlling
through analysis of sales, costs and budgets. These are the three areas, about which managers most
often ask questions and need to make decisions to improve the performance of the business. This
module can also handle cost accounting and activity-based accounting as well as a host of other
accounting functions.

Human resources (HR)

The human resources module contains functions that relate to the recruitment, management and adminis­
tration of personnel; payroll processing; and personnel training and travel. It captures employee details,
changes in those details and the distribution of pay to those employees. When employees undertake
training or travel for work purposes, it also captures this information.

Sales and distribution (SD)

The sales and distribution module contains functions related to the revenue or sales order to cash process.
It provides the ability to capture and record customer orders, check the customer’s ability to pay, execute
customer orders, ship products to customers and bill customers. It also contains a process that records
each step during picking and packing so that the system can provide the latest status on a customer’s

CHAPTER 6 Technology concepts 243

order. The module is linked to the materials management module to check product availability, and the
financial accounting module to post the sales transactions to the general ledger. See figure 6.3 for an
example of the sub-modules in the sales and distribution module.

FIGURE 6.3 Sub-modules in the sales and distribution model

Source: SAP.

Materials management (MM)

The materials management module contains functions related to the payment or purchase to pay process,
including the management of products while they are in stock. The module contains the processes for
purchase requisitions and purchase orders. It connects with the financial accounting module when pur­
chases are made from suppliers, and with the sales and distribution module when customer orders are
processed. When products arrive from suppliers, it compares what is received with what was ordered,
then adjusts the records of stock on hand. The master data for accounts payable and cash disbursements
are updated when all the source documents (purchase order, product receipt and invoice) are verified.
ERP systems support key internal business processes and financial transactions with suppliers and
customers. These systems are also increasingly reaching out toward the non-financial activities associ­
ated with suppliers and customers. For example, while an ERP system can record a purchase of raw
materials from suppliers, modules within SAP can also suggest ways of improving the sourcing of
raw materials. While an ERP system can record the sale of a product to a customer, SAP modules
can also suggest ways of improving the revenue process or the customer’s buying experience. There
are two modules that extend the internal capabilities of ERP systems to suppliers and customers by
offering mechanisms to improve supply chain management and customer relationship management
respectively. These are supply chain management (SCM) and customer relationship management
(CRM) modules. We will not discuss them here, but they are examples of how the ERP system extends
beyond the current organisation. See figure 6.4 for examples of other modules along with the materials
management module.

244 PART 2 Systems characteristics and considerations

 FIGURE 6.4 Materials management and other modules
Source: SAP.

We have discussed how ERP systems combine all the processes for a business into one system. If
an organisation wants to send data to another organisation that can be directly written into the other
organisation’s computerised accounting/hybrid/ERP system, they can use XML (eXtensible Markup
Language). Another benefit relates to the requirement for many organisations to file statutory accounts
with regulatory filing agencies. Having their ERP system coded with XBRL tags is one way to ensure
that their data is easily extracted and sent to regulatory agencies. The next section discusses the tech­
nology that is capable of doing this: XBRL.

6.4 XBRL and its role in reporting systems

and decision making
LEARNING OBJECTIVE 6.4 Explain how XBRL is used in reporting systems.
The idea behind XBRL is simple: instead of treating financial information as simply a block of text — as
in a standard web page or a printed document — XBRL provides a computer-readable tag for each item
of data. A tag can be thought of as being similar to a barcode. If we think of it this way, each piece of data
in an accounting report has a barcode attached to it and the barcode explains what the piece of data is. By
attaching meaning to strings of text, XBRL adopts a semantic approach. Companies can use XBRL to
save costs and streamline their processes for collecting and reporting financial information. Consumers of
financial data, including investors, analysts, financial institutions and regulators, can receive, find, com­
pare and analyse data much more rapidly and efficiently if it is in XBRL format. XBRL is not a pro­
prietary technology. XBRL is freely licensed and available to the public. It is based on XML and therefore
is widely available in software applications. The major benefit of XBRL is a result of introducing a set of
industry-accepted standards that provide consistency and therefore comparability of financial information.

CHAPTER 6 Technology concepts 245

 XBRL is a data standard used when generating financial reports. The importance of this standard is
that it allows semantics, or meaning, to be embedded within strings of financial data, allowing more
efficient and in-depth analysis to be conducted by users or recipients of the data. This meaning is con­
veyed by embedded tags that identify where individual pieces of data start and end within larger strings
of data. XBRL makes financial reporting to various user groups much more efficient. It can be used for
internal users and external financial reporting.
For internal users, one of the prime motivations behind the development of XBRL is the number of
times in traditional financial reporting circles that differing information needs to be supplied in paper
documents, or electronic formats that mimic paper, communicating financial results to investors, regu­
lators, government agencies and other stakeholders.
For external users of business information, XBRL represents a significant step forward in their ability
to analyse publicly available information. The vast majority of companies have websites, on which they
typically publish information relating to employment opportunities, company history and financial infor­
mation. Financial information is often presented on a web page, using html standards, or the annual
report is published as an Adobe PDF (portable document format) file, which can be downloaded and
then viewed or printed. The problem with both of these approaches is that it is difficult for users to
manipulate the information with any degree of efficiency. The advantages of PDF files are that they can
be securely locked so that figures cannot be changed — ensuring that financial reports can be printed but
not changed ensures the integrity of the financial reports. This gives the company assurance that audited
financial statements cannot be altered. For this reason, secure PDFs have become a standard way to
publish financial reports. However, the advantage to companies in ensuring that their figures are correct
on the website creates a disadvantage to those wishing to use the figures in financial statement analysis.
For example, in order to conduct analysis, users need to view the PDF financial reports, identify data of
interest and re-enter those data into other software, such as a Microsoft Excel spreadsheet. This extra
data manipulation that the user must perform represents a time cost in the analysis of the information. It
also introduces a risk of data errors when transferring the data from one source to another.
In this context, the advantages of XBRL are:
•• reduced data manipulation
•• paperless reporting
•• industry-accepted standards
•• reduced accounting time
•• recognition by main software vendors
•• interchangeable data
•• comparisons across companies.
Corporate regulators worldwide are gradually moving towards mandating XBRL for corporate filings and
reporting. The XBRL concept has strong international support, with many countries establishing local bodies
to develop and implement XBRL. Detailed information about the use of XBRL is available at www.xbrl
.org, the website of XBRL International, a consortium of companies and agencies, and www.xbrl.org/au,
the ­Australian branch of XBRL International. The Australian government’s Standard Business Reporting
­website, www.sbr.gov.au, has additional information on Australian business reporting trends and standards.
In the United States, the Securities Exchange Commission (SEC) issued a rule ‘Interactive Data to
Improve Financial Reporting’ in January 2009. The rule requires all public companies that prepare finan­
cial statements in accordance with at least US generally accepted accounting principles (GAAP) and
all foreign private issuers that prepare their financial statements using International Financial Reporting
Standards (IFRS) as issued by the International Accounting Standards Board (IASB) to provide their
financial statements to the SEC and their corporate websites in XBRL format. In addition to all financial
statement line items, companies must use XBRL to tag their footnotes in detail.
XBRL’s use is reaching a tipping point for other countries. Regulatory authorities in Europe, Australia,
Singapore, Japan, Korea and China have various XBRL financial requirements and large banks around the
world are beginning to require companies to use XBRL in their loan application and credit granting processes.

246 PART 2 Systems characteristics and considerations

 XBRL has become a standard for tagging data and transmitting it across networks and databases.
Most current software is XML compliant and can import, export and process data in XML format. XML
is an open standard for marking up data and adds meaning to individual pieces of data by surrounding it
with tags. Since XBRL is an XML vocabulary, most current software is XBRL compliant.
As it becomes the standard for financial reporting, XBRL will deliver its promise of helping com­
panies to automate required reporting processes and helping investors, analysts and users of all types to
retrieve and use financial information for investment and other decision-making purposes.
XBRL can also be used for internal purposes, particularly management reporting that involves trans­
ferring information between different countries or branches within the same company. Regardless of the
spoken or written language, the tag signifies what the item means. Using XBRL for internal purposes
means that an organisation can set up the coding structure of the items they want to tag to match what is
particularly suitable for that company.
We have reached a point where every accountant and financial professional should understand XBRL,
how to navigate and use the XBRL taxonomies, and how to create XBRL instance documents. How­
ever, XBRL is not currently a standard for filing financial accounting reports with the stock exchanges
in Australia or New Zealand. Australia’s corporate regulator, the Australian Securities and Investments
Commission (ASIC) has been able to accept XBRL lodgements since July 2010. There is very little evi­
dence that Australian corporates are using this voluntary system as yet.

6.5 Different ways to apply XBRL tags

LEARNING OBJECTIVE 6.5 Compare and contrast the different ways XBRL can used be used.
In this section we look at the different ways that XBRL tags may be applied to data. Tagging is the
process of associating a dollar value in an account, such as debtors, to the XBRL element/item in an
XBRL schema; for example, <debtors>10  000</debtors>. Along with the tagging of the items, the XBRL
element contains content items such as date, currency type and whether the item is usually a debit or a
credit. There are two main ways to code the financial accounts.
1. Attach XBRL to the accounting system.
2. Attach XBRL tags after the financial accounts have been produced.
There is debate in the accounting information systems community as to whether to tag data at the
individual transaction level when capturing the original event data in the accounting system, or to tag the
summarised outputs (i.e. at the general ledger account code level). The choice between the two options
is very important. Coding accounts once they have been produced impacts on core processes and the
data quality that will result, as mistakes are more likely using this method. However, while companies
get to grips with XBRL, this will probably be the most common method. Over time companies will
work to incorporate the XBRL into their coding structures.

XBRL tags in the accounting system

XBRL tags are available in many ERP and accounting packages. The XBRL tags are attached to the
chart of account codes. When the data in that code is transferred, the XBRL tags are attached to it.
As a result, very little work needs to be done in external financial account presentation. Also, the data
can be transferred internally and used internally using the XBRL tags. Figure 6.5 shows the process of
extracting reports from the tagged database. The main issue is to ensure the tags that are set up against
the chart of accounts codes in the general ledger are correct and have been verified. Once that is done, it
is easy to generate reports from the database.
This is the more efficient way to operate; however, you can produce your accounts in Microsoft Word or
Excel and then apply the codes (discussed in the next section). In either method, applying the correct tag
to the correct item of data is an issue of reporting quality and integrity of information (an internal control
concern). An aspect of internal control is looking at the reliability of financial reports. This requires the

CHAPTER 6 Technology concepts 247

correct tag to be coded against the correct item; for example, the debtors figure needs to be coded against
the debtors tag. When this occurs, there is reliability of the accounts when used in analysis by stakeholders.
With the tags attached to the accounting system, this can be made part of the internal audit.

XBRL tagged

Prepare reports
Tagged
database

XBRL tagged

FIGURE 6.5 Tagging the data in the database

Tagging accounts after reports have been produced

When tags are applied to the data after the reports have been created (see figure 6.6), internal control
procedures are required to check the data before it is used or filed with regulatory agencies. The next
section gives an example of how this process works using Microsoft Word. Any XML-compliant soft­
ware can be used to add XBRL tags — Microsoft Word and Excel are used in our example, as most
users have these available on their desktop.

Prepare reports
Database

Electronic reports Electronic reports

Tag reports with Tag reports with

XBRL tags XBRL tags

XBRL tagged XBRL tagged

FIGURE 6.6 Tagging the data in the electronic reports once they have been produced

248 PART 2 Systems characteristics and considerations

6.6 Benefits of XBRL
LEARNING OBJECTIVE 6.6 Justify the benefits of XBRL.
As mentioned earlier, Australia has had a voluntary system of lodging their corporate reports using
XBRL since July 2010. It appears, though, that organisations in Australia have yet to be convinced that
the benefits attributed to XBRL outweigh the costs. However, XBRL is a significant step forward for
business reporting for several reasons. First, it represents the collaboration of some of the leading indus­
trialised nations and some of the largest commercial firms. Together they are developing standards for
XBRL reporting that will apply internationally. XBRL is also significant for the impact that it will have
on users of financial information. Financial statement analysis tasks, such as searching for particular
items or information, will be made easier by the set of context-specific metadata tags that are developed
through XBRL. This will yield benefits including reduced time for information searching, greater ease
when comparing across companies (since they will all be presenting information using XBRL conven­
tions), easier interchanging of data and, potentially, paperless financial reporting.

Reduced data manipulation

Conventionally, companies report their financial information to shareholders in glossy, magazine-like
publications known as annual reports. The annual reports are also often available from the stock
exchange and on the investor section of the company’s website, usually as PDF files. It is not possible
to analyse the data from these files until it is transcribed into a spreadsheet or word processing file. This
requires the user to identify each item and enter it correctly into their software. This process is illustrated
in figure 6.7.

Business organisation EXTERNAL USERS of business reports

Financial
Re-INPUT
statements
financial data
Business
data

Re-PREPARE
financial
Preparation of
reports
business
reports

Re-INPUTTED
Business data
Regulatory Financial
documents such as statements
stock exchange
documents

FIGURE 6.7 Before XBRL, external users of financial information had to identify and re-input data before
undertaking financial analysis

CHAPTER 6 Technology concepts 249

 When accounts are tagged with XML codes, there is no need for transcription of data; the data are
ready to process. Errors that may have been introduced through misunderstanding or miskeying are
eliminated.
From a technical perspective, XBRL represents a further step forward from XML. XML allows
programs, when creating files, to label data with tags or metadata. The tags specify what each word,
number, character or group represents. XBRL takes every item that appears in a set of financial state­
ments, including the discussion and analysis, and applies a tag to it. This tag can then be used to search,
sort and manipulate data. XBRL data prepared by an organisation can be loaded into users’ software,
and users thus avoid the need to re-enter data (see figure 6.8). For example, if you want to search for
data held by a stock exchange that uses XBRL, such as the Canadian Stock Exchange, you can select the
stock exchange and download the XBRL reports directly into Microsoft Excel or Microsoft Access. In
a spreadsheet, the data tags can be used as headings. Once you have downloaded the data, you can pro­
gram formulae to perform financial statement analysis and compare the companies of interest. You can
be assured that your headings for items in current assets or current liabilities are correct. Certainly there
will be no errors introduced by you trying to find items in a paper annual report and manually typing the
figures into a spreadsheet. This is of course a significant step forward from what was previously possible
in financial statement analysis.

Business organisation EXTERNAL USERS of business reports

Financial
Business statements
data coded for coded for
XBRL XBRL

Preparation of Extract financial reporting

business data electronically (no human
reports re-input of data needed)

Regulatory Business data

Financial
documents such
statements
as stock exchange
coded for
documents
XBRL
coded for XBRL

FIGURE 6.8 After XBRL, data from financial statements can be put straight into other software for
analysis

From the company’s perspective, conventionally it has needed to reconfigure financial data, which
typically originates from the accounting information system, into the different formats required by
its external users, including shareholders, regulatory bodies such as stock exchanges and govern­
ment agencies. This represents a significant preparation cost to the company. XBRL overcomes this
problem. The underlying data are entered once, but tagged to capture the different ways in which the

250 PART 2 Systems characteristics and considerations

data will be presented. XBRL thus eliminates the need to manipulate the data to suit different users’
requirements and companies do not need to maintain separate documents for each reporting require­
ment they face.
The advantages of XBRL are discussed in greater detail in the following sections.

Paperless reporting
XBRL is well suited to paperless reporting, with reports viewed online. In contrast to the traditional
accounting cycle in which a different format of report is prepared for each different type of user, with
XBRL all information is coded once and then electronically extracted without the need for a paper-based
report.

Industry-accepted standards
XBRL has been designed through the collaboration of software companies, governments and pro­
fessional accounting communities. Therefore, there is only one version of XBRL. The XBRL stan­
dards have the support of the international and national accounting bodies and thus incorporate the
international financial reporting standards that a company would use, or a country’s generally accepted
accounting practice if they do not use international reporting standards. This high degree of coordination
has helped to develop industry-accepted standards and to avoid competition between different versions
of XBRL (a problem that has arisen with other software owned or developed by proprietary companies).
Once XBRL standards are defined, they can be taken and applied to different industries and environ­
ments through the creation of different taxonomies. For example, the Standards Based Reporting (SBR)
initiative in Australia uses its own taxonomy for the reporting requirements of government agencies in
Australia.
There are a number of issues with industry-accepted standards. One of them is that we want con­
sistent accounts so that different companies can be compared. However, at present some countries
use IFRS while the United States uses US GAAP. The international accounting bodies are working
towards one standard. Another issue relates to extensibility. If a company uses the IFRS accounts,
it can amend them by adding in special accounts particular to its business. If enough companies
add these special accounts using extensibility, the accounts cease to be comparable. It is hoped that
various industries will define what accounts they need and the industry-specific taxonomies can be
standardised to these. However, given that XBRL is just developing, it needs to be flexible enough
to encompass every business’s needs. So, consistent standards and extensibility are a conflict to be
worked through by the XBRL organisations.

Reduced accounting time

Through the application of different taxonomies and standards, the time required to prepare accounting
reports — whether for shareholders, regulators, creditors or auditors — is significantly reduced. The data
tags that form XBRL enable accounting packages to interact with other organisational databases and
prepare information to meet the requirements of different reporting formats in a quick and efficient way.
Real-time reporting becomes a possibility.

Recognition by major accounting software vendors

XBRL has been incorporated into the vast majority of enterprise resource planning (ERP) systems,
accounting packages and office software. ERP systems are used in larger, more complex organisations.
They are designed to capture a wide range of information about all business transactions and processes
related to the typical major areas in an organisation, such as sales and marketing, finance, manufacturing
and human resources. These systems link the major functions of an organisation and the organisation’s

CHAPTER 6 Technology concepts 251

suppliers and customers in the value chain. The incorporation of XBRL into these systems means the
data are relatively easily transferrable between these packages.

Interchangeable data
The interchangeability of XBRL data between the major accounting software means that once the data
is tagged it can be reused in many ways to meet differing financial reporting requirements. There is no
need to re-enter the data just because a new reporting requirement arises.

Comparisons across companies

If stock exchanges have XBRL filing as part of their filing requirements, it will be easy to download and
analyse the data of multiple companies. XBRL makes it feasible to analyse and compare huge numbers
of companies and enables small investors to do their own efficient analyses using spreadsheet data. As
mentioned previously, the data does not need to be identified, classified and re-entered, so it has an extra
element of accuracy and integrity.

Improved audit quality

Improved audit quality can occur as long as the taxonomy has correctly classified items of data at source.
As part of this process, the coding or tagging of the items does itself need to be audited to ensure that the
tagging is correct. Any changes made to the tags also need to be audited. In traditional audits, the output
of the accounts is looked at; for example, the debtors’ balances. Using XBRL, if the data is input cor­
rectly and the correct tag is applied, then the output produced from this will be correct. So the emphasis
will be on tagging the data correctly in the input processes; if this is done correctly, the accounts will be
correct.

Stakeholder benefits
XBRL can benefit external and internal reporting. It is not just used for external stakeholders such as
stock exchanges and regulatory authorities but for different purposes for different external stakeholders
in different jurisdictions. XBRL can also be used by internal users. The first part of this section mentions
the external users, which we will discuss further below. We then move on to discuss how internal users
can use XBRL within an organisation.
External stakeholders
XBRL benefits the decision-making processes of external stakeholders by making it easier and faster to
search, sort and compare financial information.
Certain jurisdictions require the use of XBRL. Examples are the United States, where public com­
panies use XBRL, and Canada, which has operated a voluntary filing scheme for many years.
The coding structures (or taxonomies) for XBRL are country-specific. For example, the United States
uses US GAAP, so US companies use the taxonomy for US GAAP. XBRL International’s website,
www.xbrl.org, provides free access to taxonomies for different countries according to what financial
reporting standards they use.
Australia and New Zealand use IFRS and so the IFRS coding structure would be used by ­Australian
and New Zealand companies. However, neither Australia nor New Zealand has mandated XBRL
reporting of companies’ financial accounts. Companies still present their data in PDF format. Australian
government agencies have developed Standard Business Reporting (SBR) for their own required reports
to government. Whether XBRL should be mandated for financial reports to stock exchanges is a matter
of current debate.
The website of XBRL (www.xbrl.org/the-standard/why/who-else-uses-xbrl/) contains a page of who
uses XBRL and for what uses — financial statements, banks or government filings.

252 PART 2 Systems characteristics and considerations

Internal stakeholders
By using XBRL, companies and other producers of financial data and business reports can
automate the processes of data collection. For example, data from different company divisions with
different accounting systems can be assembled quickly, cheaply and efficiently if the sources of
information have been upgraded to use XBRL. Once data is gathered in XBRL, different types
of reports using varying subsets of the data can be produced with minimum effort. A company
finance division, for example, could quickly and reliably generate internal management reports,
financial statements for publication, tax and other regulatory filings, as well as credit reports for
lenders.
Not only can data handling be automated, removing time-consuming, error-prone processes, but the
data can be checked by software for accuracy. Small businesses can benefit alongside large ones by
standardising and simplifying their assembly and filing of information to the authorities.
With XBRL, software developers can build tools that can be installed in a wide variety of systems
without the need to customise the interface to the company. Installation may require custom configur­
ation based on how a company wants to deploy its internal control systems, but that would likely be at
a much lower cost.
Additionally, because XBRL is an external standard that supports financial reporting based on US
GAAP and IFRS, companies will have the ability to respond to rapid changes in regulatory reporting
requirements.
The ability to consolidate acquisitions and integrate business systems has historically been chal­
lenging due to differences in data and account structures. XBRL has the potential to significantly reduce
the time and effort required to integrate new acquisitions if both companies are using the standard.
Integration would simply be a matter of consistently classifying the already tagged information. There
would be little need for the large information gathering and consolidation effort that organisations face
with acquisitions today.

6.7 XBRL concepts

LEARNING OBJECTIVE 6.7 Analyse the various concepts in using XBRL.
This section looks at how XBRL evolved from the XML language. These standards, which are data
content standards, are compared to HTML, which is a presentation standard. Even though they all use
web-based technology, they use different aspects of it.

XML and XBRL compared to HTML

The internet has become a timely and important source of information. XML and XBRL leverage
the internet. There is no need to buy additional hardware or software, as most computers have web
browsers. When you access web pages, your web browser makes these pages viewable on your screen.
A simple example is shown in figure 6.9. These web pages have been created using HTML. HTML, or
HyperText Markup Language, is the language used to present the data on websites correctly (i.e. to
format the data). The standards upon which HTML are based form a part of XML. XML, or eXtensible
Markup Language, is data about data, or metadata, specifying what different pieces of data are and
how they may be used. As described earlier, XBRL is a variant of XML developed specifically for appli­
cation in the business environment. It allows the use of HTML and XML standards in the production
and reporting of financial information, enabling financial data to be searched and manipulated through
the internet.

CHAPTER 6 Technology concepts 253

 FIGURE 6.9 A simple web page

HTML is based around standards that define how a web page will be viewed in a web browser. A
simple example is shown below. Figure 6.9 shows a web page viewed in a web browser. Figure 6.10
shows part of the HTML code used to generate this web page. For example the code <html><head>
<title>A Simple Web Page</title></head> tells the browser that ‘A Simple Web Page’ is to appear
in the title bar at the top of the browser window, while <b>View from the window</b> instructs the
browser to put the words ‘View from the window’ in bold type. The tags used in HTML are predefined
and relate to how the web page is to be presented. Opening tags and closing tags are used to specify
how enclosed content should be displayed. For example, the instruction to display a piece of text in
bold starts with the opening tag <b> and finishes with the closing tag </b>. Note that the closing
tag contains a forward slash ‘/’. The example code starts with <html>, telling the browser that the
following code is in HTML.
As we have seen, HTML has predefined tags that control how the content appears when displayed on
a computer screen. There are tags that control font size, line spacing, alignment and so on. XML, on the
other hand, is a content language. XML enables us to tag items on a web page according to what content
they contain. Consider, for example, that our financial data includes a debtors’ balance of $10  000. When
the data for the debtors’ balance is tagged, the XML code would read <debtors>$10  000</debtors>. In
this way, regardless of how this figure is displayed or formatted, it is clear that the debtors’ balance is

254 PART 2 Systems characteristics and considerations

$10  000 and, conversely, that this $10  000 is the debtors’ balance. This example shows how the tags
work as a semantic code to specify the meaning of the item. HTML and XML can exist on the same web
page. The HTML codes are used to present the data; the XML codes specify what the data are.

<html>
<head>
<title>A Simple Web Page</title>
</head>

<body>
<font face = “Arial” size = 12>
<p align = ‘center’>
<img src = “dsc200.jpg” width 82 height 87>
<b>View from the window</b></p>

...
</font></body></html>

FIGURE 6.10 A simple web page’s source code

Because the fields are tagged with the content they contain, such as <debtors>, the data are accessible
to other programs and applications. The benefits of this approach are increasingly obvious as e-business
emerges and organisations need to share data with other organisations and customers, as well as within
the organisation. At a practical level, XML allows this to happen through a set of industry-defined proto­
cols that have been built into the most popular office software (such as Microsoft Office), accounting
systems and ERP systems.
With universally agreed tags, information sharing becomes much easier. Specifications for tags are
contained in document type definitions (DTDs). A DTD is an example of a schema (see below). Dif­
ferent industries, such as the music, military, weather forecasting and finance industries, each have their
own version of XML. XBRL is a variant of XML for financial reporting. XBRL takes the concept of
XML a step further by enabling the tags to contain more data than just its content. XBRL tags contain
additional information about the data (i.e. metadata) such as time period, currency and type of standard
(e.g. IFRS). XBRL uses tags applied to data to specify what the piece of data is and how it is used, and
also to make the data searchable. The set of tags developed under XBRL represents a standard for the
business environment; thus the tag <SalesRevenue>, for example, has the same meaning — in terms of
its calculation and what the value represents — for anyone using the XBRL standards. XBRL provides
a consistent taxonomy for searching and using the data contained in web pages. This makes data search­
able and comparable. Thus, while HTML controls how the data appear on the screen, XBRL provides a
way to search the data and make them meaningful to the user.

XBRL specifications
The specifications for XBRL documents are made up of a number of components, which are described
in this section. Figure 6.11 presents an example of a web page. The data that appear on this web page are
tagged with XBRL, but notice that we cannot see this just looking at the web page. The sections below
will explain the XBRL tagging attached to the data in this web page.

CHAPTER 6 Technology concepts 255

 FIGURE 6.11 A web page coded with XBRL

XBRL taxonomies
Taxonomies are the dictionaries that define each accounting item that can be tagged in XBRL. There
are internal and external taxonomies. For example, there are internal general ledger taxonomies which
tag the chart of accounts. External taxonomies include those for US GAAP and IFRS. These taxonomies
define all the elements within each of the standards. For example, the IFRS taxonomy contains all the
account names required to use all of the IFRS standards.
Numerous taxonomies are available from XBRL International’s website, www.xbrl.org. These
taxonomies contain the files you need according to the taxonomy that is relevant to what you are
doing. An Australian or New Zealand company would use the taxonomy for International Financial
Reporting Standards (IFRS). Other available taxonomies relate to, for example, the general ledger
or insurance companies. Users can extend the taxonomy if they need additional tags to fit their busi­
ness’s industry.

Schemas
A taxonomy contains one or more schemas. A schema is a formal description of the structure and
content of a database. Schemas contain elements (see below) that are defined in accordance with the
taxonomy. They contain the definitions or standards for context items such as time periods, numerical
amounts and currency. For example, the schema in the New Zealand taxonomy defines the elements

256 PART 2 Systems characteristics and considerations

related to New Zealand GAAP, such as the use of New Zealand dollars for the measurement currency.
XML schema documents finish with the three characters .xsd and can be opened in a web browser.

Elements
A schema contains numerous elements that make up the financial statements. Each specific item that can
be tagged in a financial statement is an element. Each element, shown between two tags, is defined in the
schema. US GAAP has more than 4000 elements in its financial standards and each of these is shown
as tags in its schema. These elements relate to different items in the financial statements according to
US GAAP standards. A company would probably use only a fraction of them in any set of accounts,
depending on what financial statement items they have.
Figure 6.12 shows an excerpt of the XBRL tagging of the first asset item (the cash and cash equiv­
alents data) in figure 6.11.

<element id=”nz-gp_bankBalancesDepositsAndCashcashAndCashEquivalents”
name=”bankBalancesDepositsAndCashcashAndCashEquivalents”
type=”xbrli:monetaryItemType” xbrli:periodType=”instant”
xbrli:balance=”debit” />

– <w:customXml w:uri=”www.xbrl.org/nz/fr/gaap/2004-05-12”
w:element=”bankBalancesDepositsAndCashcashAndCashEquivalentscashEquivalents”>
<w:t>142.4</w:t>

FIGURE 6.12 XBRL code relating to cash and cash equivalents

The first set of tags shows:

•• the element id (from the schema), ‘nz-gp_bankBalancesDepositsAndCashcashAndCashEquivalents’,
which refers to New Zealand GAAP, which is International Financial Reporting Standards
•• the unique name of the account — ‘bankBalancesDepositsAndCashcashAndCashEquivalents’
•• the type ‘monetaryItemType’ (monetary type means it is measured in the currency)
•• a period type ‘periodType’ (in this case it is an instant, but it could also be a period of time)
•• the element’s normal balance type ‘balance’ — in this case debit.
The second set of tags specifies which taxonomy this information came from — ‘www.xbrl.org/nz/fr/
gaap/2004-05-12’. The XBRL has come from www.xbrl.org. It is using the New Zealand GAAP and this
was last updated on 12 May 2004. Lastly, the amount for the item was ‘<w:t>142.4</w:t>’, which shows
that the value of cash and cash equivalents was 142.4.

Linkbases
An XBRL taxonomy contains one or more linkbases. Linkbases define the relationships between the different
elements (e.g. current assets and long-term assets make up the assets selection). Linkbases control how the
data elements are linked together, how the values in the elements are combined, and how they are to be pre­
sented. Various different links are needed. For example, individual current assets add together to give total cur­
rent assets. The different asset types — current assets and long-term assets — add together to give total assets.
In an XML-based system, all of these links are made by linkbases. The various linkbases are as follows.
•• Calculation linkbase. A calculation linkbase is used to relate XBRL concepts through the application of
basic calculation rules (e.g. assets equals liabilities plus shareholder capital). This ensures the accuracy
of the many accounting equations that comprise XBRL reports and enables XBRL software to interpret
these relationships correctly and automatically derive the correct values from the input data.
•• Label linkbase. The label linkbase provides human-readable strings for concepts. Using the label
linkbase, a user can look up, for example, the definition of ‘cash and cash equivalents’. The definition

CHAPTER 6 Technology concepts 257

 it will give depends on what accounting standard has been chosen in the taxonomy. For example,
the US GAAP taxonomy will give the US GAAP definition of cash and cash equivalents; the IFRS
taxonomy will give the IFRS definition. The label linkbase enables you, when you are coding, to link
into the relevant standard and find the definition of the item you are looking at to make sure that you
are tagging it correctly. This facility can also support multiple languages.
•• Reference linkbase. The reference linkbase associates concepts with the citation of some body of
authoritative literature; for example, a securities exchange ruling.
•• Definition linkbase. The definition linkbase associates concepts with other concepts using a variety of
rules such as ‘is a part of ’.
•• Presentation linkbase. The presentation linkbase associates concepts with other concepts so that the
resulting relations can guide the creation of a visualisation of the accounts.

Instance documents
When XBRL tagging is applied to a file containing data (e.g. an income statement), the XBRL-tagged
document is called an instance document. The account figures, such as income, are coded for what
they are — for income, the period to which that figure relates and the monetary value. The instance
document contains information about the organisation’s financial statements at one instant in time,
along with other contextual information such as monetary items, debit or credit and balance sheet or
income statement items.

FIGURE 6.13 The original coding of the item using Microsoft Word

258 PART 2 Systems characteristics and considerations

Creating an instance document
The first step in coding accounts in XBRL is to download the appropriate taxonomy from XBRL Inter­
national’s website, www.xbrl.org. The taxonomy contains one or more schema files and linkbases. The
taxonomy must be installed in the software that is to be used to tag the reports. Once that is done, the
file is opened, the tags are applied to the data and the result is saved as an .xml file to create an instance
document. This XML document is now able to be transferred and read.
Specialist XBRL tagging programs are available, including many freeware and shareware programs.
In addition, the widely used Microsoft Office suite has XML and, therefore, XBRL capabilities. XML
and XBRL have been supported in Microsoft Word since 1995, but work much more seamlessly in the
current version of Microsoft Word. Figure 6.13 shows the web page from figure 6.11 as it was tagged in
Microsoft Word. It is possible within Word to switch the tags on and off. Without the tags switched on,
the Word file would look much like the output in figure 6.11.
The example illustrated in figure 6.11 focused on the cash and cash equivalents data, but of course all
the other data in the financial statements would be similarly tagged.

Tagging accounts using XBRL

Common business software such as word processing, spreadsheet and database packages can be used for
XBRL. This method is used when you are coding a set of accounts after they have been produced. There
are several steps to coding accounts in XBRL.
1. Accounts must be in a word processing package such as Microsoft Word or a spreadsheet package
such as Microsoft Excel. An example is shown in figure 6.14.
2. The taxonomy can be downloaded from XBRL International’s website at www.xbrl.org. The first
page of the schema is shown in figure 6.15. Remember that schemas are large documents — they
contain every element in the financial reporting standards that you are using (in this case, IFRS)
and there are more than 4000 items in the financial reporting standards. The schema is many
pages long.
3. The schema and other files must be attached to the word processing or spreadsheet software. In
Microsoft Word, you use the Developer Tab — Schema — Add Schema. You then attach the schemas
and linkbases downloaded from xbrl.org.
4. The accounts must be tagged. Select the figure in the left-hand column relating to what you want to
code and then select the tag from the right-hand list. Figure 6.16 shows the accounts and account tags
ready to apply to the account codes. The account tags make a very long list. In Microsoft Word, they
are presented as a list. In many of the purchased, shareware and freeware products, they are presented
as hierarchies and colour coded, so it makes finding, for example, current assets within the asset hier­
archy a lot easier.
5. All the data must be tagged as described in step 4. The document is then saved as an XML file. It will
then retain the codes attached to the data.

CHAPTER 6 Technology concepts 259

 FIGURE 6.14 Word document with no XBRL tagging

FIGURE 6.15 Schema for New Zealand GAAP (IFRS)

260 PART 2 Systems characteristics and considerations

 FIGURE 6.16 Coding accounts using XBRL tags in Microsoft Word

Figure 6.17 shows what the Microsoft Word file looks like after ‘cash and cash equivalents’ has
been coded, but the codes are not visible. You can see that ‘Show the XML tags in the document’ is
not ticked (indicated by a large arrow in the diagram) and therefore you cannot see the XBRL tags.
The XBRL codes are present, and when the figures are transferred these content tags will be trans­
ferred with them, but when you view the document you will not necessarily want to see them all
the time.
In figure 6.18, the ‘Show the XML tags in the document’ check box has been checked and we can see
that the figure of 142.4 for cash and cash equivalents has been coded (i.e. it is enclosed by the opening
code and closing code). When the ‘Show the XML tags in the document’ check box is unchecked, indi­
viduals who use the document are not aware of the coding it contains. In other words, it looks like a
normal Microsoft Word document.

CHAPTER 6 Technology concepts 261

 FIGURE 6.17 Word document with XBRL coding not visible

FIGURE 6.18 Word document with XBRL coding visible

262 PART 2 Systems characteristics and considerations

6.8 Cloud computing
LEARNING OBJECTIVE 6.8 Categorise the different types of Cloud-based computing including Software
as a Service.
Cloud computing is a model of computing that provides computer services through the internet to a
pooled set of resources that provide these services. This pooled set of resources is usually infrastructure
in data centres and software. There are various types of cloud computing, the most important to account­
ants probably being software services called Software as a Service (SaaS). Other services include Infra­
structure as a Service (IaaS), Hardware as a Service (HaaS) and Platform as a Service (PaaS).
Each type of cloud service is discussed below; however, the cloud-computing model generally has
some advantages. The main advantage is that these different services can be accessed on an as-needed
basis. Therefore, as your business grows you can use more services or resources as you need them. The
services are accessed through the internet on stand-alone computers on a 24/7 model, so no special setup
is needed to access them. The resources you wish to use are assigned to you on demand and you do not
need to know where the computing resources are housed. Google has massive server farms in the USA.
The number of resources you use can be increased or decreased to meet the changing user demand that
you require. You are charged for what you actually use.
The computing services offered by each type of cloud computing is different.

Cloud Infrastructure as a Service (IaaS)

Cloud Infrastructure as a Service (IaaS) customers obtain the use of processing, storage, networking
and other infrastructure resources from cloud service providers to run their information systems on, and
pay for them on a usage basis rather than purchasing their own infrastructure. This can include storage
services (HaaS).

Cloud Platform as a Service (PaaS)

With Platform as a Service (PaaS), customers obtain the infrastructure services as discussed above in
IaaS, as well as programming tools so that users can design their own applications, and pay for them on
a usage basis.

Software as a Service (SaaS)

As part of the systems development effort, a common choice faced by organisations is whether they should
buy the required software, develop it themselves or customise an existing package to suit their needs. In the
modern environment of technology where the internet is omnipresent, a fourth option has emerged: the use
of software-as-a-service (SaaS) providers, previously known as application service providers (some ven­
dors use the alternative term on-demand computing). SaaS providers are organisations that offer software
applications that can be leased by a range of clients. The leased programs are typically made available to
the customers through the use of internet and portal technology.2 SaaS services are a derivative of the tra­
ditional outsourcing function, representing a way for small- and mid-sized organisations to gain access
to the systems and technologies — such as ERP systems and CRM technology — that were traditionally
only available to larger organisations.3 Motivations for using SaaS may include reducing the total cost of
ownership, focusing on core competencies, arranging a more predictable expenditure pattern for IT, being
more efficient and matching the technology used by competitors. Technological reasons for using SaaS
may include a lack of adequate skills within the organisation, quicker implementation time, a shift of risk
of ownership and the ability to have best technology in place.4
SaaS providers offer organisations several advantages that would not necessarily be available under
conventional acquisition methods, including cost savings, lower initial investment, better performance
and the ability to focus on dealing with key strategy and competency issues rather than peripheral

CHAPTER 6 Technology concepts 263

t­echnology-based issues. Cost savings from the use of SaaS come from the economies of scale that SaaS
providers enjoy in providing the required software. The SaaS provider can serve many users and is there­
fore able to develop and maintain the software at a cheaper cost per user than if firms were to develop
the software themselves. Organisations using SaaS are potentially able to benefit from a lower total cost
of ownership. Using the services of a SaaS provider can also present a way for the organisation to ben­
efit from the use of applications without needing to make a large initial investment. This leads to the ser­
vice being implemented within the organisation more quickly and also allows the organisation to place
its emphasis on its competencies, rather than worrying about IT and peripheral issues associated with IT.
SaaS thus allows an organisation to focus its attention on what it does best. The SaaS provider can also
assist the subscribing organisation with its bank of support services and technical advice and training,
thus ensuring qualified technical support, the cost of which is not the responsibility of the organisation
but rather of the SaaS provider.
SaaS also presents some disadvantages that an organisation should take into consideration. These
include the degree of customisation required, the reliability of the SaaS, security, speed and infra­
structure. Speed, along with 24/7 access, can be addressed through the service agreement with the SaaS
provider. Infrastructure, if it is needed, can be purchased from an IaaS provider, as discussed above. The
degree of customisation of applications provided through a SaaS provider may not be as high as that for
applications which have been developed in-house. This may mean that their applications may do all of
the general tasks required by an organisation but not specific tasks unique to it.
A further issue for the potential customer to consider is the SaaS provider’s reliability, which can be
broken up into two main areas: quality of service and long-term stability. The issue of reliability of ser­
vice is a fairly obvious consideration: is the SaaS provider able to offer the quality and level of support
that is required? The level of service that is required from the SaaS provider will normally be specified
in the service level agreement, a document specifying what responsibilities the SaaS provider has and
how they are to be fulfilled. Typically, this document will specify responsibilities in periods of normal
operation, as well as what is to happen in the event of maintenance, service and disaster.
The long-term stability aspect of reliability acknowledges that, for the subscribing organisation,
a fair reliance is being placed on the SaaS provider to be able to provide the services in the mid to
long term. This presupposes that the SaaS provider is able to keep operating in the mid to long term.
As a result, organisations should consider factors such as the financial stability of the SaaS provider
before committing to a particular one, because a SaaS provider that collapses can leave an organisation
without valuable services, which can be disruptive, if not disastrous. One way of minimising this risk
is for the client to require that the service-level agreement provides for a copy of the software code
to be deposited in escrow (i.e. in trust with a third party). If the SaaS provider fails for any reason,
then the code is made available to the client to use on their own system. This requires, first, that the
escrow copy is kept current and, second, that the code and associated documentation are sufficiently
user-friendly for the code to be successfully installed by the client company. This may not be an option
that the SaaS provider is open to.
A final issue for organisations to consider when evaluating a SaaS provider is the security of ser­
vices offered. Security in this sense refers to how safe the data are that reside with the SaaS provider,
especially if they are related to key strategic activities or areas of operation. Because the SaaS provider
potentially can be providing the same set of services to many different organisations at once, the concern
about the security of proprietary data is a very real one.5
Software-as-a-service is not a new concept. SaaS represents a different avenue for businesses to go down,
allowing them to focus on their core competencies and strategically important activities. However, use of a
SaaS provider is no different from any other systems project, requiring careful planning and investigation.
At their best, SaaS providers ‘offer the ability for a company to focus on its core competencies, reduce value
chain activity costs and enhance overall competitive advantage’.6 At their worst, however, they can cause dis­
ruption to an organisation’s operations and result in significant down time and costs.

264 PART 2 Systems characteristics and considerations

6.9 Big data
LEARNING OBJECTIVE 6.9 Analyse the concept of big data and how it is used.
Over the last few years, we as users are creating more and more data that systems are recording.
When we access Facebook or tweet or play YouTube clips, we are accessing social media, and infor­
mation is now available on what tweets are being retweeted, what YouTube clips are going viral and
what hash tags are trending. The quantity of social media transactions is enormous — and all this
data is being recorded. Because it is being recorded, it can now be analysed. Previously this was not
the case.
The data being generated by social media is semi-structured and comes from many sources: tweets,
Facebook posts, blogs, browsing patterns of online shoppers. And other systems are also generating this
sort of data: for example, traffic systems that monitor motorways in real time, environmental manage­
ment systems that manage air-conditioning in buildings through the sensor data collected and computer­
ised monitoring of yacht races. All this data needs to be stored so that we can analyse it. However, this
data does not fit with the traditional database models that have been developed for business, so a whole
new area of database design has come about for recording this type of data. This data is called big data
and databases have been designed that can accommodate the huge amount of data from social media
and real-time systems. Once data is stored in these databases, we can then interrogate it for information.
These databases must have the capacity to store a lot of data and must be structured to store data that is
incomplete. Think of how you would store browsing patterns of consumers on an online shopping site.
Given the site has been operating for years, you would have a lot of information that a business could
use, but not all of it would be useful.
The databases that have been created to contain this big data are not like traditional databases. They
do not support relational database concepts and they do not support structured query language (SQL).
They are called noSQL databases and the data that they contain is known as sparse data. This is data
generated from web services and sensor or environmental systems, for example, but not every option on
a page is accessed and only data that is accessed is recorded. So, from the given options on a page, only
a few may be accessed and recorded. Therefore, if you were looking at a normal database structure, you
would have many empty attribute columns, and thus the data you have would be sparse. To illustrate
what sparse data is, let’s take another example. When an individual records data on their Facebook page,
they do not record all their data. They may choose not to include a photo, or other information such as
first name, last name, degree, employer, income, country of birth, favourite hobbies, friends, or relation­
ship status. Some of the attributes may be applicable to them, but they may choose not to include them.
This means the resulting data is sparse data.
Big data is currently being used to analyse sales and buyer behaviour by stores such as Walmart,
Netflix and eBay to improve their operations, and it is likely that accountants will become involved
in the world of big data as it involves data being searched on their websites. However, it is unlikely
that social media data will form part of data analysis for marketing purposes in accounting firms. As
an accountant, an organisation you may work for may be interested in big data because it contains
patterns that are useful insights into customer behaviour or even financial markets behaviour. Cap­
turing, storing and analysing big data can be expensive for a business and you will need to make sure
that any investment in big data will be able to assist decision making or improve operations within
the organisation.

Other technologies
Other technologies that may affect accounting information systems in the future are discussed in this
section. Wearable technology such as smart watches and cloth that are able to access your computer

CHAPTER 6 Technology concepts 265

system already exists, although the use of this technology in accounting information systems isn’t cur­
rently very high. However, with the release of the apple watch with apps, this may change over the next
few years.
Then there is Google Glass — glasses that can record anything the wearer is looking at, access the
internet and even post what they are seeing as a video — which may be an issue if employees wear them
in an office that contains confidential information. This may also have an impact on privacy if the wear­
er’s actions are being recorded without their knowledge. All of these issues seem to have transpired for
the test group of Google Glass users so the widespread use of this wearable technology does not seem
likely at this stage.
Bring your own device (BYOD) has had a profound effect on businesses. Many individuals have
phones, iPads and phablets. Phablets are phone/tablet devices that are bigger than a phone and smaller
than a tablet and have increased functionality. Individuals who own these devices want to use them to
access their work email systems, so organisations have had to prepare policies on the types of devices
that are allowed to access their network and the type of security that has to be installed on an individ­
ually owned phone/phablet/iPad to enable it to access the organisation’s information systems. In par­
ticular, these policies stipulate the type of access the user is permitted — email only or email and access
to accounting systems. Given the devices are privately owned by individuals, any such data/access needs
to be efficiently removed when the individual leaves the organisation and updates need to be made to
the devices.

AIS FOCUS 6.1

Phablets for accountants?

Are phablets the next big thing for accounting firms? A phablet is a smartphone and tablet computer
hybrid. It is bigger than a smartphone and smaller than a tablet computer, such as an iPad or an
iPhone Plus.7 Many accounting professionals have opted to use a phablet (one device), which means
that they no longer need to carry around a smartphone and an iPad (two devices). ‘­Businesspeople
who love the phablet design are likely happy about their new freedom. No longer do professionals
need to carry around multiple devices that only have a few differences between them. They are
able to use one device for both calls and data work, a liberating feeling for those with heavy brief-
cases or purses.’8 Because the phablet is larger than a smartphone, data entry (particularly via pull-
down screens) is easier, and it also has a larger screen for output. However, there are some faults:
for instance, editing a document can be difficult and storing a phablet in a pocket or handbag is
also problematic due to the larger dimensions. Additionally, some applications are not available
on the phablet. ‘Mobile computing is a space where consumers are still trying to figure out what
mix of devices and screen sizes will suit them best. What works well today could very well shift.’9
­Regardless, accounting professionals will still need to decide whether this is a good device, or
whether the traditional multiple device combination (smartphone and tablet computer or laptop) will
be a preferable way to mobilise their accounting work.
Robotics is affecting the shop floor, but still has limited influence on the accounting profession. Busi-
nesses such as Amazon and Zappos use robots to pick the stock in their warehouses. Amazon, for
example, has installed 15 000 new robotic employees in ten of its US warehouses. These robots came
from Amazon’s acquisition of Keva in 2012 for US$775 million.10 The computer processing of orders
occurs when an incoming order is received. The computer system dispatches a robot to pick up the rack
that the item requested is on and bring the rack to the person who is picking the goods for shipping.
This is fast and efficient as the warehouse uses only robots and less room is therefore needed, as space
is not required for humans to walk between the racks. The robots work for several hours and then line
up and recharge themselves on their own. Most of the impact of the robots occurs in the picking and
packing of goods in the accounting cycle.
Social media, on the other hand, has had a profound effect on the accounting profession, with many
social media items becoming part of the business desktop. Social media communication tools such as
Yammer, Lynx and Skype for Business are attached to individuals’ email accounts and they can com-
municate business issues on a device that looks very like Facebook for Business.

266 PART 2 Systems characteristics and considerations

SUMMARY
6.1 Recommend why organisations are motivated to implement or upgrade enterprise
resource planning (ERP) systems.
ERP systems originated from the Materials Requisition Planning (MRP) systems that incorporated the
production planning and production within their systems. The ERP systems that evolved from the orig­
inal MRP systems incorporated production planning and production and linked the resources needed in
these modules to accounting, finance, marketing, sales and human resources modules. Therefore, the
motivation for implementing or upgrading to an ERP product lies in obtaining a product that contains
accounts for all aspects of your business. For example, with production and accounting, the information
that needs to flow between them such as the amount of product produced and the cost of production can
flow between the modules without any need for rekeying data. The data from production is entered into
the accounting module in the correct general ledger accounts under double-entry accounting. Stand-
alone accounting systems that accommodate only the accounting function need to have another system
for production and that data needs to be re-entered into the accounting module.
6.2 Categorise the key business processes that ERP systems support.
ERP systems support the five key business processes that involve the major functions in an organisation:
1. revenue, sales or order to cash
2. payment, purchases or purchase to pay
3. production, manufacturing or conversion
4. human resources and payroll
5. general ledger and financial reporting.
ERP supports these processes through allowing data capture, processing and report production for key
decision making in these areas.
6.3 Describe the main modules in an ERP system through using SAP as an example.
The main modules in the SAP ERP system are financial accounting (FI), controlling and profitability
analysis (CO), human resources (HR), sales and distribution (SD) and materials management (MM).
Most ERP systems have similar modules and similar functionality. These modules cover the five main
business processes. The sales and distribution module enables the capture and processing of customer
orders, checking of customers’ ability to pay, shipping the products to customers and billing customers.
The materials management module contains functions related to the payment process, including the
management of products while they are in stock. The financial accounting module processes all the
accounting transactions for the business, and the data from sales and distribution and materials manage­
ment are integrated in its chart of accounts. The human resources module provides the functionality to
recruit employees, manage employees and their remuneration, and enable payroll processing to occur, as
well as additional functions such as employee training. The controlling and profitability module supports
internal management accounting for the business, which includes budgets and variances to budgets, as
well as analysis of sales and costs.
6.4 Explain how XBRL is used in reporting systems.
Different stakeholders such as company managers, employees, analysts and shareholders require infor­
mation to make strategic and operational decisions. Information is only accurate, timely and relevant if
data are captured, stored and managed efficiently and effectively. XBRL enables the data to be coded for
its content. Data in an XBRL format can be easily managed and manipulated by common productivity
packages.
6.5 Compare and contrast the different ways XBRL can be used.
XBRL can be attached to your ERP or accounting package if your accounting vendor provides this.
Once XBRL is attached to the ERP or accounting package, accounts can be coded according to the tax­
onomy in use. XBRL can also be applied to accounts that have been created in Word or Excel by using
freeware or shareware, or Microsoft Word or Excel to apply the codes.

CHAPTER 6 Technology concepts 267

6.6 Justify the benefits of XBRL.
XBRL provides efficiencies for internal and external users of financial data. Among the advantages are
reduced data re-entry and manipulation, the ability for paperless reporting, widespread industry accept­
ance of data standards, reduced accounting time, recognition by major software vendors, interchange­
ability and comparability of data, and improved audit quality.
6.7 Analyse the various concepts in using XBRL.
XML tags enable us to code any data with a description of its content. The tag travels with the data as it
is transferred through multiple software packages. The coding system can be created internally as long
as those who code the data have the coding system and those who receive the data also have the coding
system to enable them to read the data. Alternatively, the tagging system can be an already created
one. XBRL International’s website, www.xbrl.org, contains the taxonomies for the financial reporting
standards. This provides a consistent coding structure for companies that use International Financial
Reporting Standards. These codes don’t just code the data for its content; they also add additional meta­
data. The codes are contained in taxonomies that anyone can use. XBRL requires a taxonomy related
to the applicable reporting rules; for example, the International Financial Reporting Standards. The
taxonomy contains one or more schemas which contain the individual elements, such as debtors and
creditors, for tagging data. The schema contains additional information such as the time period and the
currency used. Linkbases contain calculation, reference and linking information relating to the elements.
Once the taxonomy is installed in the software package being used to tag the data, the data must be in
a Microsoft Word or Excel document. Tags are applied to the data. Doing this creates an instance docu­
ment. This instance document is saved as .xml and can be used to store and transmit data between com­
puters for various analyses, both internally and externally.
6.8 Categorise the different types of Cloud-based computing including Software as a Service.
The different types of Cloud-based computing services include Software as a Service (SaaS), which allows
various types of software to be leased and used. Examples of SaaS are Google Apps, Microsoft Office 365,
ERPs such as SAP’s Business byDesign and customer relationship management software such as e.Sales­
force.com. There is also Infrastructure as a Service (IaaS), which provides cloud storage for data offline. With
IaaS, customers buy from cloud service providers the use of processing, storage, networking and other infra­
structure resources on which to run their information systems, rather than purchasing their own infrastructure.
This can include the storage service, Hardware as a Service (HaaS). With HaaS, various components of hard­
ware can be supplied over the internet. There is also Platform as a Service (PaaS), which consists of Infrastruc­
ture as a Service and programming tools that allow users to design their own applications.
6.9 Analyse the concept of big data and how it is used.
Big data is the type of data that is being generated from, for example, social media pages and sensor
data. There is a large amount of this data and it varies widely. Storing this sort of data in traditional
database structures does not work and this has led to the development of noSQL databases. Once the
data is stored, it can be analysed for patterns so that a business can use the data to make operational
decisions. This data is known as sparse data. For example, when people shop on your business’s
e-commerce site, data may be recorded, such as the items they click on, how long they stay on each
page, which items are purchased and which items were viewed but not purchased. Through analysing
all of this data, decisions around what products should be promoted and on which places on the web
pages may be decided.

KEY TERMS
Big data The massive amount of web, system or sensor generated data that existing database
management tools have difficulty capturing, storing and managing.
Cloud computing A model of computing whereby computing services are obtained from a cloud
provider over the internet and paid for based on a usage model.

268 PART 2 Systems characteristics and considerations

Customer relationship management (CRM) Software designed with the specific purpose of viewing
the organisation’s data from a customer-centric perspective that monitors and helps the management
of customer interactions with the organisation. Examples include Siebel and SAP.
Document type definition (DTD) A set of specifications for XML tags.
Elements Each specific item tagged in a financial statement is an element.
ERP systems Software designed to capture a wide range of information about all key business events
including accounting and finance, human resources, sales and marketing, and manufacturing.
eXtensible Business Reporting Language (XBRL) A data standard used when generating financial reports.
eXtensible Markup Language (XML) A hypertext language which is used to add syntax to strings
of data by embedding semantic tags. Useful for transaction processing where the data syntax is
predictable and well defined.
Hardware as a Service (HaaS) A model of computing whereby hardware computing services are
obtained from a cloud provider over the internet and paid for on a usage basis.
HTML (HyperText Markup Language) A language that a web browser uses to display a web page
correctly, based on a set of standards.
Infrastructure as a Service (IaaS) A model of computing whereby computing infrastructure such as
hardware, software, data, network and services are obtained from a cloud provider over the internet
and paid for on a usage basis.
Instance document An XBRL-tagged document containing information about an organisation’s
financial statements at one instant in time.
Linkbases The parts of an XBRL taxonomy that control how the data elements are linked together,
how the values in the elements are combined, and how they are to be presented.
Material Requirements Planning (MRP) MRP systems are computing systems which account for
the logistics and production in an organisation.
Metadata Data that describes other data.
noSQL databases Databases generally used for big data that do not follow relational database rules or
have the ability to use SQL to interrogate the data for information.
Platform as a Service (PaaS) A model of computing whereby computing infrastructure as well as
programming tools are obtained from a cloud provider over the internet and paid for on a usage basis.
Schema A formal description of the structure and content of a database.
Semantic approach An approach focused on meaning.
Service level agreement A document specifying what responsibilities the software-as-a-service
provider has and how these are to be fulfilled.
Software as a Service (SaaS) Companies that provide software applications that can be leased by a
range of clients.
Sparse data Data from web services and sensor or environmental systems is considered to be sparse
data in that it provides many attributes but the attributes instances recorded can be very small.
Supply chain management (SCM) Systems that monitor and assist the management of supplier
interactions with the organisation.
Taxonomies The dictionaries that define each accounting item that can be tagged in XBRL.

DISCUSSION QUESTIONS
6.1 Explain how an ERP system integrates the activities within an organisation.(LO1)
6.2 Explain the benefits of an ERP system.(LO1)
6.3 What key business processes does an ERP system support?(LO2)
6.4 Explain how an ERP system supports key business processes.(LO2)
6.5 Describe the typical modules in the SAP ERP system.(LO3)
6.6 Discuss how XBRL is used in reporting systems.(LO4)
6.7 What are the benefits of XBRL for internal and external users of financial information?(LO6)
6.8 Describe the current state of adoption of XBRL reporting.(LO6)

CHAPTER 6 Technology concepts 269

 6.9 How has XBRL evolved from HTML and XML?(LO7)
6.10 In what ways can a document be coded with XBRL?(LO7)
6.11 Discuss what cloud computing is.(LO8)
6.12 Explain the concept of big data.(LO9)

SELF-TEST ACTIVITIES
6.1 The four major functions that are linked by an ERP system are:(LO2)
(a) sales/marking, manufacturing, accounting/finance, and human resources.
(b) sales/marketing, manufacturing, customer and accounting/finance.
(c) customer, sales/marketing, production, accounting/finance and human resources.
(d) customer, sales/marketing, production, accounting/finance.
6.2 HTML code:(LO7)
(a) uniquely identifies each computer connected to the internet.
(b) provides tags for financial statement data displayed on the web.
(c) provides standards that specify a set of tags for data on the web.
(d) provides instructions for the display of a web page.
6.3 Which of the following is not an advantage of XBRL?(LO6)
(a) Interchangeable data
(b) Less accurate financial reporting
(c) Recognition by major accounting package vendors
(d) Paperless reporting
6.4 Which of the following best describes the relationship between accounting information
systems and accounting standards?(LO4)
(a) Accounting information systems must comply with all accounting standards.
(b) Accounting standards dictate the way an accounting information system must store
and handle financial data.
(c) Accounting information systems that recognise and comply with accounting standards are
advantageous for tax purposes.
(d) There is no direct relationship between accounting standards and accounting information systems.
6.5 XBRL will potentially assist in strengthening information transparency because:(LO6)
(a) it offers greater search power and customised information for different stakeholders.
(b) it is a typology based on specific business reporting requirements.
(c) it is technically superior to html and reduces the reporting time by businesses.
(d) it offers paperless reporting based on industry-specific standards.
6.6 XML does not:
(a) offer a set of industry-based protocols for sharing data in e-business exchanges.(LO7)
(b) add data tags after reports are created.
(c) add data tags before reports are created.
(d) define relationships between data.
6.7 Which of the following statements is not true about cloud computing?(LO8)
(a) It removes all concern about data and systems security for businesses.
(b) It relies on the internet as the platform for delivering services to users.
(c) It consists of three types of services: SaaS, IaaS (including HaaS) and PaaS.
(d) It allows smaller firms to use resources that may have been previously unaffordable.
6.8 What best describes the big data phenomenon:(LO9)
(a) computing software that can heal itself.
(b) green computing initiatives.
(c) software services that can be leased.
(d) data that has come from social media or environmental systems.

270 PART 2 Systems characteristics and considerations

PROBLEMS
6.1 Green Grocer is the name of a business that runs eight bookstores around the country. It sells
all types of books, from fiction, non-fiction and children’s to technical and academic books. The
Green Grocer has decided to opt for an ERP system. Explain the importance of an ERP system for
businesses and how it will benefit the Green Grocer book chain. (LO1, LO2)
6.2 Cafe Corner Ltd is a successful food company that has developed a large market presence in the
meat pie industry. The company has several thousand shareholders, as well as many key suppliers of
financial and production resources. In a heated discussion with one of its major lenders, Al’s Bank, it
was suggested to the CEO of Cafe Corner Ltd that in order for funding for further expansion plans to go
ahead the business would need to improve its reporting. Al’s Bank wanted Cafe Corner Ltd to make its
financial data more accessible and easier to analyse and compare, both across time and also with that
of other companies. Upon hearing this, the CEO of Cafe Corner Ltd, who did not have an information
systems background, responded with ‘We cannot do that without totally redesigning our system and
totally altering our reporting system in order to give you direct access.’ The bank manager responded,
‘What about adopting XBRL? Some of our other clients have used it quite successfully.’
The CEO of Cafe Corner Ltd was dumbfounded — he thought XBRL was what controlled the
display of web pages and could not see how it would answer the bank’s problem. Thus he left the
meeting confused, flustered and uncertain about where to head from here.
You have been asked by the CEO of Cafe Corner Ltd to clear up his confusion. He requests the
following of you:
(a) Prepare an outline that describes the differences between XBRL and HTML.(LO7)
(b) Conduct a search and identify some of the organisations that are using XBRL.
Briefly describe the benefits these organisations get from XBRL.(LO5)
(c) Prepare a report for your client outlining step by step what they would need to
do to implement XBRL in their reporting.(LO7)
6.3 Discuss the advantages for preparers and users of the SBR program in Australia.
SBR was developed as a standard for governmental reporting in Australia. It is used to facilitate and cut
compliance costs in reporting to the government. Rather than using XBRL, the Australian government
came up with its own taxonomy for how items need to be classified for reporting. The accounting, financial
and payroll software has the SBR codes applied for all government reporting. This means that, when
a government organisation reports to government, they have exactly the same standards of reporting.
SBR was designed in conjunction with the Australian, state and territory governments and their software
professionals. The Australian government also consulted the Netherlands government who had used it on a
smaller scale. They also ensured that the chief agency CEOs were supportive of SBR. (LO6)
The SBR model includes the adoption of a standards-based language to report to government,
functionality in financial, accounting and payroll software to pre-fill and electronically lodge
forms, a single authentication credential to report to many agencies, and a receipt in real time to
confirm the report has been received. It sounds pretty simple as a business proposition and most
leaders can understand this and learn to expect it.
SBR requires 12 agencies to communicate their reporting needs and be able to receive
reporting information in a single language. Rather than adopt one of the agency’s reporting
standards, SBR adopted XBRL as a standard, which was originally developed by the accounting
community for financial reporting. A key task from the outset was to ensure the overall SBR
design would reduce the reporting burden for business and generate the expected savings.11

The main issue faced with the adoption of the SBR standards by the Australian government was
the need to find competent advisers with knowledge of its application. The other important issue
was educating accounting staff on its adoption and use. It was a new technology but its adoption
and use were reasonably straightforward. The use of internet software and XML meant that it did

CHAPTER 6 Technology concepts 271

 not require an investment in software. The development of SBR reporting has the potential to save the
governmental reporting institutions significant time and money.
6.4 Prepare a report explaining the two approaches to XBRL tagging — tags at the end of the
financial reporting process and during information processing.(LO5)
6.5 XBRL is ensuring the standardisation of financial reports. Why is this important in today’s global
environment?(LO6)
6.6 Discuss why there are multiple taxonomies. Give some examples of different taxonomies and
why they are used. (LO6, LO7)
6.7 You have been asked to advise on a possible XBRL installation for Emporium. Emporium is a
multistore retail business that sells products such as DVDs, CDs, mp3 players, game consoles and
TVs. In addition to these retail sales, Emporium also sells music, games and DVDs via its website.
The company is required to report to shareholders, regulatory bodies and the tax office/inland revenue
department. Emporium currently has an ERP system with SAP installed on it. With reference to
Emporium, discuss the benefits and costs of using XBRL in this organisation.(LO6)
6.8 Explain the purpose of metadata. What metadata does XBRL store and how?(LO7)
6.9 Why do accountants need an understanding of XBRL? Isn’t this something we should
leave up to the information technology people? (LO4, LO5, LO6)
6.10 Should XBRL be mandated in each reporting jurisdiction? Give arguments for and against.(LO4)
6.11 Using the Telecom Corporation of NZ Limited financial statements and the IFRS, find the
appropriate element tag for all the items in the 2013 group financial statements for the current
and non-current assets. Discuss your codes. Are there any where questions arise about which
is the correct element code? Prepare a report for the company outlining the issues and which
accounts you require someone to make a judgement call on.(LO7)

Statement of financial position

As at 30 June 2013 and 2012
GROUP PARENT
AS AT 30 JUNE 2013 2012 2013 2012
(DOLLARS IN MILLIONS) NOTES NZ$M NZ$M NZ$M NZ$M
Current assets:
Cash 118 185 — —
Short-term derivative assets 12    5    1 — —
Receivables and prepayments 12 658 684    1    1
Taxation recoverable    4   53   99   84
Inventories 14   53   49 — —
Total current assets 838 972 100   85
Non-current assets:
Long-term investments 15   77   57 7  155 8  129
Long-term receivables and prepayments 13   159 222 — —
Long-term derivative assets 12    1    1 — —
Intangible assets 16 1  071 900 — —
Property, plant and equipment 17 1  347 1  515 — —
Total non-current assets 2  655 2  695 7  155 8  129
Total assets 3  493 3  667 7  255 8  214
Source: http://investors.sparknz.co.nz/FormBuilder/_Resource/_module/XZdfKzNUJ02K93habZUuMw/reports/
annual/Telecom-AR-2013.pdf.
More Telecom NZ information is available on their website: http://investors.telecom.co.nz/
Investor-Centre/?page=Latest-Results.

272 PART 2 Systems characteristics and considerations

6.12 As part of a team, individually search the Web for information on cloud computing models.
Particularly look for accounting packages that use Software as a Service (SaaS) such as ERP
SAP’s Business byDesign. Discuss what is required to install this package.(LO8)
6.13 Search for examples on the internet where big data has been used to generate
new insights.(LO9)

FURTHER READING
Bartley, J, Chen, AYS & Taylor, EZ 2010, ‘A comparison of XBRL filings to corporate 10-Ks —
evidence from the voluntary filing program’, working paper, http://ssrn.com/abstract=1397658.
Capozzoli, E & Farewell, S 2010, ‘SEC XBRL filing requirements: an instructional case on tagging
financial statement disclosures’, Issues in Accounting Education, vol. 25, no. 3, pp. 489–511.
Coronel, C, Morris, S, & Rob, P 2012, Database systems: design, implementation and management,
11th edn, Cengage Learning, Boston, MA.
Coronel, C, Morris, S, Rob, P & Crockett, K 2013, Database principles: fundamentals of design, imple-
mentation and management, 2nd edn, Cengage Learning, Boston, MA.
Debreceny, RS, Chandra, A, Cheh, JJ, Guithues, D, Hannon, NJ, Hutchison, PD, Janvrin, D, Jones, RA,
Lamberton, B, Lymer, A, Mascha, M, Nehmer, R, Roohani, S, Srivastava, RP, Trabelsi, S, Tribunella,
T, Trites, G & Vasarhelyi, MA (Working Party of the AAA Information Systems and Artificial Intel­
ligence/Emerging Technologies Sections) 2005, ‘Financial reporting in XBRL on the SEC’s EDGAR
system: a critique and evaluation’, Journal of Information Systems, vol. 19, no. 2, Fall, pp. 191–210.
Debreceny, R & Farewell, S 2010, ‘Adios! Airways: an assignment on mapping financial statements to
the US GAAP XBRL taxonomy’, Issues in Accounting Education, vol. 25, no. 3, pp. 465–88.
Debreceny, R & Farewell, S 2010, ‘XBRL in the accounting curriculum’, Issues in Accounting E ­ ducation,
vol. 25, no. 3, pp. 379–403.
Grant, GH, Sharifi, M & Grant, CT 2010, ‘Creating XBRL instance documents with Rivet’s Dragon
Tag® software’, The Accounting Educators’ Journal, vol. XX, pp. 135–56.
Hodge, FD, Kennedy, JJ & Maines, LA 2004, ‘Does search-facilitating technology improve the trans­
parency of financial reporting?’, The Accounting Review, vol. 79, no. 3, July, pp. 687–703.
Laudon, KC & Laudon JP 2015, Essentials of MIS, 11th edn, Pearson, Essex, UK.
Locke, J & Lowe, A 2007, ‘XBRL: an (open) source of enlightenment or disillusion?’, European
Accounting Review, vol. 16, no. 3, pp. 585–623.
Madden, P 2010, ‘SBR lift-off’, National Accountant, June/July, p. 35.
Pinsker, R & Shaomin, L 2008, ‘Costs and benefits of XBRL adoption: early evidence’, Communi­
cations of ACM, vol. 51, no. 3, March, pp. 47–50.
SBR website, www.sbr.gov.au/content/public.
Srivastava, RP & Kogan, A 2010, ‘Assurance on XBRL instance document: a conceptual framework of
assertions’, International Journal of Accounting Information Systems, vol. 11, pp. 261–73.
Srivastava, RP & Kogan, A 2010, ‘Response to discussion on “Assurance on XBRL instance document:
a conceptual framework of assertions”’, International Journal of Accounting Information Systems,
vol. 11, pp. 282–84.
Trites, G 2010, ‘Discussion of “Assurance on XBRL instance document: a conceptual framework of
assertions”’, International Journal of Accounting Information Systems, vol. 11, pp. 279–81.
White, CE Jr 2010, ‘Jim’s Sporting Goods: the move to XBRL reporting’, Issues in Accounting
Education, vol. 25, no. 3, pp. 425–63.
XBRL website, www.xbrl.org.

SELF-TEST ANSWERS
6.1 a, 6.2 d, 6.3 b, 6.4 a, 6.5 a, 6.6 d, 6.7 a, 6.8 d.

CHAPTER 6 Technology concepts 273

ENDNOTES
1. Quora website, www.quora.com/How-useful-are-SAP-certifications-for-business-analytics, 13 April 2015.
2. Smith, AD & Rupp, WT 2002, ‘Application service providers (AS): moving downstream to enhance competitive advantage’,
Information Management and Computer Security, vol. 10, nos 2/3, pp. 64–72; Smith David, J, McCarthy, WE & Sommer, BS
2001, ‘Agility: the key to survival of the fittest in the software market’, unpublished paper.
3. Sofiane Tebboune 2001, ‘Application service provision: origins and development’, Business Process Management Journal,
vol. 9, no. 6, pp. 722–34.
4. Sofiane Tebboune 2001, p. 726.
5. Sofiane Tebboune, p. 727.
6. Smith & Rupp 2002, p. 67.
7. ‘Phablets are big in Asia-Pacific, equalling tablets and laptops combined’ 2013, The Guardian, www.theguardian.com/
technology/2013/sep/02/phablets-asia-pacific-tablets-laptops-growth.
8. ‘Are phablets the next big thing for accounting professionals’ 2015, 13 April, www.sage.com/ca/accountant/news-and-tips/article-
details?title=Are-phablets-the-next-big-thing-for-accounting-professionals%3F&id=0f8962f9-5d5c-4190-80b2-924992da33cc.
9. ibid.
10. ‘Meet the robots filling your cyber Monday Amazon orders’ 2014, Bloomberg, 1 December, www.youtube.com/
watch?v=ADgSTMla3EU.
11. Madden, P 2010, ‘Cut compliance costs’, CIO, August, p. 19.

ACKNOWLEDGEMENTS
Figures 6.2 to 6.4: © 2015 SAP SE or an SAP affiliate company. All rights reserved.
Photo: © Andrey_Popov / Shutterstock.com.

274 PART 2 Systems characteristics and considerations

CHAPTER 7

Systems mapping
and documentation
LEA RNIN G OBJE CTIVE S

After studying this chapter, you should be able to:

7.1 justify why systems documentation is important to the organisation and the accounting function
7.2 communicate how systems documentation can be used as a part of business process redesign and
re-engineering
7.3 reflect on how the accountant and auditor can be exposed to systems documentation
7.4 appraise how legislative reform has impacted systems documentation
7.5 recognise and interpret different forms of systems documentation
7.6 explain the concept of a balanced set of systems documentation
7.7 generate different forms of systems documentation
7.8 compare and contrast different forms of systems documentation.
Introduction
Have you ever travelled to a new city or country and arrived in the middle of a thriving metropolis
only to discover you do not know where you are or in which direction you should be heading? Alter-
natively, recall your first few days on campus, as you tried to find your way around the layout of the
buildings and the location of key lecture theatres, coffee shops and libraries. The navigation process
can be tough  .  .  .  especially if you have no assistance and are in a totally new environment. However,
with a map, or some reference material, finding your way around suddenly becomes a whole lot
easier.
It is the same with information systems. A system without any ‘maps’ to explain how the system
works is a potential problem  .  .  .  just like arriving at Victoria Station in London without knowing where
you are, or in which direction you need to head to find your pre-booked accommodation. Instead of
looking for coffee shops and accommodation, as an accountant, you will be looking for the operation of
business processes, internal controls and data flows. With the appropriate systems documentation, which
is the road map for understanding and navigating the business, navigating a system becomes a lot easier.
This makes other tasks, like redesigning and auditing a system, easier to accomplish and ensures they
are done with the full scope of the information system’s operations in mind.
This chapter will introduce you to some different techniques for mapping a business process, begin-
ning with the process map, or ‘swim lanes’ approach. The discussion will then move on to data flow
diagrams (DFDs) — including the context diagram, logical DFD and physical DFD. Following this, the
systems flowchart will be introduced. The aim in going through each of these documentation forms is
to enable you to (1) understand some of the different ways that a system can be diagrammatically repre-
sented, (2) prepare your own set of systems documentation, and (3) see the relationships among some of
the different forms of systems documentation.

276 PART 2 Systems characteristics and considerations

7.1 The purpose of systems documentation
LEARNING OBJECTIVE 7.1 Justify why systems documentation is important to the organisation and the
accounting function.
A business process is defined as the activities that work together to achieve business objectives. An
information system — the collection of data and processing, storage and generation of outputs, involving
people, processes, technology, hardware and software — is a support for the business process. A busi-
ness process may involve various information systems interacting with each other, for example, sales,
marketing and finance. The emphasis in this chapter is on being able to depict the systems and their
interaction across the business process, and also on being aware of data flows and how the data moves
through a business process. As such, when we talk about documenting a business process we are showing
the interactions with the information systems enabling that process.
Systems documentation, as mentioned in the introduction, is a way of visually depicting the oper-
ations of a system. The documentation can come in a variety of forms, depending on the perspective of
the system that needs to be represented. Essentially, when we prepare systems documentation we will
answer one or more of the following questions.
•• Who is involved?
•• What activities occur?
•• Where do the activities occur?
•• Why do the activities occur?
•• Where do the activities fit within the rest of the organisation?
When we look at the three types of documentation in the following sections — process maps, DFDs
and systems flowcharts — we will see that each addresses at least one of the above questions. In fact,
some of the documentation types address several of the questions. However, what we will also notice is
that each of the documentation types addresses the questions in a different manner. As a result, it is not
possible to say which form of documentation is better or which is more important — it all depends on
what we want to know about the system.
Process maps provide a simple graphical representation of a business process, detailing the activities
that occur, the areas of the business responsible for completing the activities, and any decisions that need
to be made as part of the process.
Data flow diagrams (DFDs) are graphical representations of where data flows within a system and
can have three forms: the context diagram, physical DFD and logical DFD. The context diagram pro-
vides a representation of the system of interest and the entities that provide inputs to, or receive outputs
from, the system of interest. The system of interest is the system or process that is the focus of the
documentation. It will have a clear boundary or scope. The physical data flow diagram provides details
of the entities involved in a process and the flows among those entities, as well as their interaction with
external entities. The logical data flow diagram illustrates the processes that take place within a system,
the flows between these processes, and how these processes interact with the external entities that pro-
vide inputs to, or receive outputs from, the system of interest. There is no need to be too concerned about
the distinction between internal and external entities and the finer points that differentiate the types of
DFDs at this point: these concepts will be explained in more detail further on in the chapter.
Systems flowcharts illustrate a system and its inputs, processes and outputs in more detail than a
process map or DFD. They provide information about the documents and processes performed within
a system, as well as who is involved in the system. You will be introduced to the different symbols and
notations, and how to read and draw a flowchart later in the chapter.
Many accounting students ask why they need to know about systems documentation, since a consider-
able amount of their accounting studies involves executing debits and credits. Such a view of accounting
ignores the important role of the accounting profession in relation to information systems and the broader
business environment. Accordingly, we will now spend some time answering the question, ‘Why is it impor-
tant that accountants know about the various forms of systems documentation?’ As you will find out in

CHAPTER 7 Systems mapping and documentation 277

the next section, there are many reasons why you, as an accountant, need to be able to prepare and under-
stand systems documentation. Whether you end up in a career as an accountant, consultant, auditor or pro-
grammer .  or follow just about any other business-related career path, you will be involved in a system at
some stage. Whether that involvement is through your being a user of a system, or a designer or a manager
overseeing the use and design of a system, it is imperative that you understand how the system is set up and
operates. Increasingly, there are also compelling legal reasons for preparing systems documentation, as we
will explore.

7.2 Role of systems documentation in process

redesign and re-engineering
LEARNING OBJECTIVE 7.2 Communicate how systems documentation can be used as a part of
business process redesign and re-engineering.
In chapter 2 we discussed the concept of the business process and how it is central to the operation of
the organisation. We also mentioned the idea of business process re-engineering (BPR) — the procedure
undertaken by an organisation looking to significantly restructure the operation of a business process
and improve the process’s performance. There are several reasons BPR may be required, including the
potential for the business to gain a competitive advantage.
How is redesign and re-engineering done? The first essential step is to understand how the existing
process operates, identifying the activities that occur, the people involved, the parts of the organisation
that interact with the process and the trail of data that moves through the process, to name just a few
aspects. This extensive analysis requires an ability to get inside the business process. One way that this
can be achieved is by understanding and reviewing the systems documentation for the existing process.
The systems documentation provides an overview of the sequence of activities in the business process;
for example, the logical DFD will show the key process activities that occur and the data that is needed
and generated within each process; the physical DFD will provide a perspective on who is involved in
the process (i.e. the people and their respective functional areas). Similarly, a flowchart will show the
movement of data and documents between functional areas and personnel and allow the analysis of
what occurs and who is involved. Such a perspective is a useful starting point for any re-engineering or
systems redesign project. Booth points out that an analysis of process documentation as part of process
redesign can allow for the identification of such aspects as where activities can run in parallel, where
paper items can be eliminated, where unnecessary data collection can be removed and where the same
activity is performed multiple times.1 Each of these represents potential ways of ‘trimming the fat’ from
a business process, but is possible only through a thorough understanding of process operation, and thus
a thorough understanding of the associated systems documentation.

7.3 Role of accountant in accurate reporting and

preserving corporate memory
LEARNING OBJECTIVE 7.3 Reflect on how the accountant and auditor can be exposed to systems
documentation.
As mentioned above, chapter 2 discussed the process perspective and how an organisation’s design
might be changed in a BPR effort. It showed how enterprise resource planning (ERP) systems can have
a part to play in this effort. For the adoption of an ERP system to be successful, or for BPR to yield
benefits, an organisation must first understand its existing business processes. One way it can do this
is through systems documentation. For consultants coming into an organisation and assisting in imple-
menting an ERP system, or managing a re-engineering effort, systems documentation will be one of the
first ports of call in understanding how the business operates. Accountants also play a role in systems

278 PART 2 Systems characteristics and considerations

documentation. That is, the key piece of knowledge the accountant can offer the organisation in situ-
ations of implementing new systems, designing new systems or adopting new modifications to a system
concerns the need for well-designed internal controls. The means through which this information can be
communicated in systems development is through systems documentation. When systems development
is undertaken, the accountant (and the auditor) will be interested in reviewing the documentation that
shows how the new system will operate, paying particular attention to the design and functioning of the
internal controls to ensure data quality is not compromised.
Alternatively, in starting a new organisation and building new business processes, there is a need to
record their design. The original designers of the business process will not always be with the organ-
isation — people leave, get fired, die — making it important that all the knowledge of a process’s oper-
ations is captured before it is too late. Systems documentation is important in preserving the corporate
memory of the process.

Auditing and systems documentation

Closer to the accounting front, systems documentation plays a key role in the execution of an external
financial statement audit. According to Australian Auditing Standard ASA 200 Overall Objectives
of the Independent Auditor and the Conduct of an Audit in Accordance with Australian Auditing
Standards, ‘the purpose of an audit is to enhance the degree of confidence of intended users in the
financial report. This is achieved by the expression of an opinion by the auditor on whether the finan-
cial report is prepared, in all material respects, in accordance with an applicable financial reporting
framework’.2 This means that a financial statement auditor will need to understand the business pro-
cesses that are used in handling the various transactions in which an entity engages. Paragraph 18 of
ASA 315 requires the following.
The auditor shall obtain an understanding of the information system, including the related business pro-
cesses, relevant to financial reporting, including the following areas:
(a) The classes of transactions in the entity’s operations that are significant to the financial report;
(b) The procedures, within both information technology (IT) and manual systems, by which those
transactions are initiated, recorded, processed, corrected as necessary, transferred to the general
ledger and reported in the financial report;
(c) The related accounting records, supporting information and specific accounts in the financial report
that are used to initiate, record, process and report transactions; this includes the correction of
incorrect information and how information is transferred to the general ledger. The records may be
in either manual or electronic form;
(d) How the information system captures events and conditions, other than transactions, that are signifi-
cant to the financial report;
(e) The financial reporting process used to prepare the entity’s financial report, including significant
accounting estimates and disclosures; and
(f) Controls surrounding journal entries, including non-standard journal entries used to record non-­
recurring, unusual transactions or adjustments.3
The requirements of ASA 315, paragraph 18(a) are such that the major groups of transactions
that an entity participates in must be understood by the auditor. This translates to, amongst other
things, knowledge and awareness of the business processes and transaction cycles that are a part of
the organisation’s activities. We discussed the generic concept of a business process in chapter 2. In
future chapters we will examine specific examples of business processes. For now, the key point for
you to be aware of is the need to understand how a business process works and the fact that systems
documentation is one way of gaining and recording that understanding. The understanding of pro-
cesses includes, as is mentioned in paragraph 18(b) of ASA 315, the commencement of transactions,
the steps followed in processing the transaction and how the transaction impacts on the financial
reports. This requires the auditor to obtain and document evidence about the operation of the business

CHAPTER 7 Systems mapping and documentation 279

processes. The requirement to document the understanding of a business process and its internal con-
trols is left up to the auditor’s professional judgement under the revised ASA 315; however, an earlier
version of the standard did specify that documentation includes techniques such as ‘narrative descrip-
tions, questionnaires, check lists and flow charts’.4 As is noted by Booth, ‘Only by describing the
operation of a process can areas of poor understanding be highlighted’.5 In other words, the best way
to ensure that you know how a process works is to try to explain it to someone else, that is, to pre-
pare systems documentation.
In gaining this understanding of a business process, the auditor will be concerned with how data is
handled, the steps that are followed, the internal controls that are built into the process and the potential
for errors to occur that could result in the financial statements being materially misstated. One of the ways
the auditor can do this is through the observation and inspection of documents within the organisation,
with both the Australian6 and New Zealand7 (in New Zealand, AS-302 and its replacement ISA (NZ) 315,
which came into effect in 2008 following international harmonisation of auditing standards and was
updated in June 2009) auditing standards mentioning that this can include such documentation sources as
organisation charts, procedures manuals and, potentially, systems documentation. Research also supports
the importance of systems documentation to the auditor, with Bradford et al.8 finding that 41 per cent of
respondents surveyed (who were all members of the Institute of Management Accountants and had roles
including auditing, accounting and financial controlling) used flowcharts to assess internal controls, while
58 per cent used flowcharts to evaluate the current system within an organisation.

7.4 The law and systems documentation

LEARNING OBJECTIVE 7.4 Appraise how legislative reform has impacted systems documentation.
Auditors are also facing legislative pressure to use systems documentation. In Australia, the auditing
standards referred to above now have the force of law. As such, auditors now must comply with the
prescribed standards when carrying out an audit, including using and preparing appropriate documen-
tation. In addition, as a result of the introduction of the Sarbanes–Oxley Act in the United States, organ-
isations are now facing legal pressures to ensure that adequate systems documentation exists within the
organisation. Sarbanes–Oxley was brought into existence with the purpose of protecting investors ‘by
improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and
for other purposes’.9 While Sarbanes–Oxley is a piece of US legislation, it has implications beyond the
shores of the United States since some of its provisions apply to foreign companies that are listed on US
stock markets. As such, some Australian and New Zealand firms listed on US stock markets have had to
confront the requirements of Sarbanes–Oxley and work towards being Sarbanes–Oxley compliant, since
its provisions became binding on all firms trading on US stock exchanges from 15 July 2006.
Section 404 of the Sarbanes–Oxley legislation impacts documentation. This section requires organisations
to put in place, review and have procedures for the management of internal controls. In addition, these con-
trols and management techniques are subject to an audit by an external auditor as part of the annual financial
report audit. The management and recording of internal controls includes the preparation of documentation
on how the controls work.10 Accordingly, it is now imperative that those within the organisation, as well as
those auditing the organisation, are familiar with systems documentation techniques.
A publication by PricewaterhouseCoopers,11 which aimed to provide advice for companies faced with
the prospect of Sarbanes–Oxley compliance, makes abundantly clear the increased role of systems docu-
mentation for those within the organisation and for external auditors. PricewaterhouseCoopers comment,
The effect of section 404, and related regulations, is that companies and their auditors put a much
greater emphasis on documentation than in the past. This applies at two levels. First, the controls must
be documented so that management can assess their design and test them. Second, in the testing, the
execution of the controls should have been evidenced in some way. One US company representative
said that ‘good documentation early on was crucial. We had always done it at a desk level but this was
raising it up a level to have top-level flow charts’.12

280 PART 2 Systems characteristics and considerations

 In effect, whether you are the accountant within a firm or the auditor of a firm, you are required to be
able to work with systems documentation.
As a result of the requirements of auditing standards, most of the large international accounting and
consulting firms now use and rely increasingly on systems documentation, whether as part of providing
a routine audit or providing consulting advice to reconfigure a business process.13
Systems documentation also serves a very important role within an organisation. That is, it provides
a record of how the organisation’s systems are set up and supposed to operate. When problems arise in
a process, changes need to be made to a process, or internal controls need to be designed, the systems
documentation will invariably be a point of reference.

7.5 Reading systems documentation

LEARNING OBJECTIVE 7.5 Recognise and interpret different forms of systems documentation.
Having established the importance of systems documentation to the accountant and the need to visualise
the functioning of the accounting information system, we will now examine some of the different types
of systems documentation. In particular, we will examine process maps, DFDs and systems flowcharts.
In this section, we will look at how to read and interpret different types of systems documentation, while
in the next section we will go through the steps in preparing systems documentation.
While we will examine process maps, DFDs (including context diagrams, and logical and physical
DFDs) and systems flowcharts, it should be noted that there are many other forms of systems docu-
mentation available, including entity–relationship (E-R) diagrams (which were discussed in chapter 3),
resources–events–agents diagrams and Business Process Modelling Language (BPML) diagrams. Dis-
cussion of these other forms is beyond the scope of this chapter. The documentation techniques we
will cover in this chapter are typically the forms of documentation used by accounting professionals in
recording the operation of a business process, gaining an understanding of a process, evaluating con-
trols in a process and designing or changing a process.14 The use of the various types of documentation
is summarised in table 7.1.15 As is evident from the results in the table, accounting professionals use a
range of systems documentation formats in their day-to-day duties, and most accountants will use more
than one form of systems documentation. Also, AIS Focus 7.1 discusses some documentation issues for
the accounting professional.

TABLE 7.1 Frequency and purpose of usage of systems documentation method

Overall usage of
documentation How the specific documentation is used

Evaluate Design or Assess internal Describe

Documentation Number Percent current system change system controls business process
method using using % % % %

System flowcharts 187 46 58 45 47 79

DFDs 85 21 51 47 35 68

E-R diagrams 56 14 36 25 36 61

REA diagrams 81 20 49 30 49 65

Process maps 115 29 47 23 38 76

UML 24 6 46 33 42 38

No technique 164 41 n/a n/a n/a n/a

CHAPTER 7 Systems mapping and documentation 281

 AIS FOCUS 7.1

The role of software in systems documentation

With the recent run of corporate collapses and the global financial crisis prompting questions to be
levelled at the management of organisations, as well as those responsible for auditing and reviewing
the processes of organisations, pressure has emerged for professionals to be literate in the different
documentation techniques available to them. One area where this pressure has been felt is in the
auditing profession, with independent auditors now required to document their understanding of the
processes in an organisation and the basis for any risk assessments that they may make in the conduct
of the audit. In order to handle these requirements, auditors are increasingly turning to software to help
them manage the different forms of documentation and ensure it is linked correctly into the audit pro-
cess. Typically, the auditor would look towards electronic working paper tools as a way of automating
the audit process. Increasingly, they will also be required to understand business processes and the
sources of risk within these processes, with this also needing to be documented. This has made sys-
tems documentation such as process maps and systems flowcharts an important tool in the auditor’s
array of skills.16

Entities
Before we begin the process of reading systems documentation, it is important that you are familiar
with the conventions for identifying who and what is included in systems documentation. The central
technique for answering this question is to focus on the entities that are part of the business process or
system. Entities refer to the people and things that are a part of the process. An entity is any person or
thing involved in the activities of a business process. Entities can be further classified as being either
internal or external. The distinction between internal and external is dependent on (a) the process that is
being documented and (b) the functions and tasks that are carried out by the entity. The concept of an
entity is also used in preparing databases. (Note that in the database context an entity is something about
which data is gathered. In a systems documentation context an entity is a person or thing that is involved
in the execution of a process. It is feasible that the entities shown in systems documentation could have
corresponding database entities; for example, employees will appear in systems documentation and will
appear in databases as entities. Be aware, however, that the perspective is different. In this chapter we
focus on what the entities are involved in. The database chapters focus on what data about entities are
gathered and how they are organised.)
In chapter 2, it was mentioned that a business process is set up to achieve a specific purpose or objec-
tive within the organisation. The logical extension of this idea is that a process will have a defined
starting point and finishing point — a clear boundary that specifies the business process’s scope and
operation. First, when we are preparing systems documentation, it is important to be clear about the pro-
cess being documented and to clearly focus on that process alone. If you are documenting the sales pro-
cess, for example, then focus on the sales process. What happens in other processes or other parts of the
organisation is not relevant to the documentation being prepared for the sales process. Being clear on the
scope or domain covered by the process being documented is the first step to being clear about the enti-
ties within the process. An analogy would be if you were asked in an exam to describe how you spent
last weekend. If you were to also write about what you did on the preceding weekdays, such discussion
would not be relevant — it would be beyond the scope of the question. Being clear on the boundaries for
the system you are documenting is important — knowing where the system of interest starts and stops is
critical for documentation preparation.
The second step is to be clear about what each entity does within a process. When we look at a written
description of a process, such as in figure 7.1 (which we look at in further detail shortly), we notice
that there are several different people and things mentioned as being involved in the process. However,
what should also be clear is that each entity performs a different function within the process. This is the
important distinction when classifying entities as either internal or external.

282 PART 2 Systems characteristics and considerations

 An external entity is any entity that provides inputs into a process or receives outputs from a process.
An entity external to the process does not process data — it merely provides/sends or receives data. This
is where clarity about the process being documented is important; that is, an entity may be external to
one process but internal to another. This will become apparent as we look at specific business processes
(or transaction cycles) in later chapters.
In contrast to external entities, an internal entity is defined as an entity that processes or transforms
the data within the business process of interest (the one that is being documented). When we refer to data
being processed or transformed, we are referring to activities in which the data is used. Transforming or
processing data is more than just sending or receiving data — it is about applying the data to the specific
tasks and requirements within the business process being documented. Some key words to look for that
indicate that data is being transformed or processed within a process include reviews, confirms, recon-
ciles, enters data, approves, batches, calculates, authorises, compares, annotates, prepares, records, sorts
and matches. Such verbs indicate that the activity is more than just sending and receiving. These verbs
tell us that the data is being used by an entity.
As examples of some of the typical activities that suggest data is being processed or transformed, read
the following explanations.
•• Comparing data — the data from one source is reconciled to data from another source.
•• Entering data — data is converted from one format (i.e. paper document) to another format (i.e.
computer data) or vice versa.
•• Reviewing reports — the information in the report is processed (whether manually or by a computer)
in order to reach some sort of decision or conclusion.
•• Approving documents or events — details about an event are considered and authorisation is provided.
In order to provide the approval, the details need to be processed and evaluated against a set of criteria.
In other words, the person who must provide the approval does so after processing the details they
have available to them.
•• Batching documents — sorting documents and grouping them based on a criterion. This will typically
involve summarising them as well; for example, calculating a batch total (i.e. how many documents
are in a batch).
•• Annotating documents — could include writing comments or amendments on the document or
initialling a document to provide approval or proof that it has been reviewed. Annotating a document
typically requires that the document be read and the details understood by the reader, so that suitable
annotations can be applied.
In summary, the key in determining whether an entity is internal or external is the activities that the
entity performs. If the entity’s sole activities involve sending or receiving data, they are considered
external. In contrast, if the entity performs data processing or transformation, it is considered internal.
Remember also that this classification depends on the process (i.e. an entity can be external to one pro-
cess but internal to another), so make sure you are clear on the process being documented.

The narrative
The starting point for systems documentation is the process narrative. The process narrative is a written
description of how the process operates. Typically, the process narrative will be prepared by observing
a process in operation and interviewing the key participants in the process. Having observed the process
and carried out the interviews, the accountant will write a text-based chronological description of the
process. The advantage of the process narrative is that it is readily accessible to anyone who can read.
This can make it a popular form for documenting a process. However, the process narrative is subject
to limitations where a deeper analysis and a better understanding of the process is required. One of the
limitations inherent in the process narrative is that its preparation and readability are contingent on the
writer’s writing style. Some people may write in a verbose manner, while others may be extremely brief
in their preparation of the narrative. Additionally, written work can be subject to different interpretations

CHAPTER 7 Systems mapping and documentation 283

and may lead to two people interpreting the process in different ways. Consequently, you would seldom
expect a process narrative to be the sole source of systems documentation. However, this is not to say
that it is without a purpose, for it provides the basis of the documentation we are about to explore.
Shown in figure 7.1 is an example of a process narrative. We will refer to this case in working through
the reading of systems documentation, so take time to familiarise yourself with its contents.
As you read through the narrative pay particular attention to the people, places and things that are
involved in the process — as we mentioned earlier, these are referred to as entities. Also focus on what
each entity is doing. Remember back to chapter 2 on business processes and chapter 1 where the concept
of inputs–processes–outputs was referred to, and apply these ideas to the case in figure 7.1. For example,
consider: What inputs are being used? What processes/activities are being carried out using the inputs?
What outputs are generated as a result? We will return to this emphasis when we look at preparing the
system documentation in the next section.

The requesting department sends a paper purchase requisition to the purchasing officer. When the
purchasing officer receives the purchase requisition they enter the item number of the goods required
into the computer. The computer retrieves and displays the product details and a list of approved sup-
pliers for that product. The purchasing officer checks that the product description matches the goods
requested, and then selects a supplier for the goods. The computer creates and displays a purchase
order containing the supplier and product details. The purchasing officer enters the quantity of goods
required, and then clicks on the ‘Confirm purchase order’ button. The computer creates and saves the
purchase order. The purchase requisition is then stamped as ‘Entered’ and filed in the purchase requi-
sitions awaiting order file.
Each Wednesday, the computer retrieves and displays the confirmed purchase orders for the pur-
chasing supervisor to review online. After the supervisor has reviewed an order, they click on the
‘Approve and print’ button and three copies of the approved purchase order are printed. The purchasing
supervisor signs all three copies and puts them in the mail for delivery. One copy is sent to the supplier,
a second copy is sent to the requesting department, and the third copy is given to the purchasing officer
who matches it with the purchase requisition and files it in the finalised purchase requisitions file.

FIGURE 7.1 Process narrative example

Process narrative table

The process narrative table is a means of summarising the narrative in a systematic way to emphasise
which entities are involved in the process, which activities are being undertaken during the process, what
inputs are required for each activity, and what outputs are produced by each activity. The structure of
this table is shown in table 7.2, which has been completed for the example narrative shown in figure 7.1.
There are a few things that you should notice about the process narrative table as follows.
1. The table follows the chronological order of the process narrative, so entities are listed in the order
in which they are involved in the process. Their order in the process is indicated in the first column,
titled ‘No.’.
2. An entity will appear more than once in the table if it performs more than one activity. Examples here
include the purchasing officer and the computer, which perform several activities at different stages
of the process.
3. The ‘Activity’ column contains a brief description of the specific action or task that is being carried
out. This column represents the ‘what is being done’ aspect of the process. It tells us what the entity
is doing.
4. The ‘Inputs required’ column refers to the data and documents required for the entity to be able to
carry out the activity. For example, in activity 2, the purchasing officer is not able to enter the details
of what is being purchased until they have the purchase requisition. The data written on the paper
document is the source of the data being input by the purchasing officer.

284 PART 2 Systems characteristics and considerations

5. The ‘Outputs produced’ column refers to the outputs created during the activity, both electronic and
paper. For example, in activity 15 the computer prints three copies of the purchase order. These docu­
ments are an output of activity 15.
6. The rows of the process narrative table should be read in conjunction with each other. Taking a row
on its own may not make total sense, but when a specific activity is considered in relation to the
antecedent and subsequent activities, the rows provide a more meaningful and clear perspective. For
example, the outputs from activity 15 (three printed copies of the purchase order) are an input to
activity 16 (the purchasing supervisor signs the purchase order), creating the output from activity 16
(three copies of the signed printed purchase order).

TABLE 7.2 Process narrative table

No. Entity Activity Inputs required Outputs produced

1 Requesting department Sends purchase requisition Purchase requisition

2 Purchasing officer Enters item number into Purchase requisition Entered item number
computer

3 Computer Extracts product and supplier Entered item number Product and supplier data
data

4 Computer Displays product and supplier Product and supplier data Displayed product and
details supplier

5 Purchasing officer Checks product description Displayed product purchase Checked purchase requisition
requisition

6 Purchasing officer Selects supplier from list Displayed suppliers Selected supplier

7 Computer Creates and displays purchase Selected supplier Displayed purchase order
order product data

8 Purchasing officer Enters quantity requested and Quantity details Confirmed purchase order
confirms purchase order Purchase requisition
Displayed purchase order

9 Computer Creates and saves purchase Confirmed purchase order Saved purchase order
order

10 Purchasing officer Stamps purchase requisition Purchase requisition Stamped purchase

requisition

11 Purchasing officer Files purchase requisition Stamped purchase Filed purchase requisition
requisition

12 Computer Extracts and displays Automated date driven Displayed purchase order
confirmed purchase order request for purchase order

13 Purchasing supervisor Reviews purchase order Displayed purchase order Reviewed purchase order
details

14 Purchasing supervisor Approves purchase order and Reviewed purchase order Approved purchase order
requests print and printing request

15 Computer Saves and prints purchase Approved purchase order Printed purchase order
order (3 copies)

16 Purchasing supervisor Signs purchase orders Printed purchase orders Signed purchase orders

17 Purchasing supervisor Sends purchase order to Copy 1 purchase order

supplier

(continued)

CHAPTER 7 Systems mapping and documentation 285

TABLE 7.2 (continued)

No. Entity Activity Inputs required Outputs produced

18 Purchasing supervisor Sends purchase order to Copy 2 purchase order

requesting department

19 Purchasing supervisor Sends purchase order to Copy 3 purchase order Despatched purchase order
purchasing officer

20 Purchasing officer Retrieves purchase requisition Copy 3 purchase order Relevant purchase requisition

21 Purchasing officer Matches purchase order and Copy 3 purchase order Matched purchase requisition
requisition Purchase requisition and purchase order

22 Purchasing officer Files matched documents Matched purchase requisition Finalised purchase requisition
and purchase order

You may also notice that some of the input and output cells in the table are blank. Examples are
activities in 1, 17 and 18. These blank cells are because these activities are being performed by entities
that are external to our system of interest. As such, we have no insight into the inputs required for the
external entity to prepare and send data, or the outputs produced by the external entity after it receives
our data. We only document what is included in the narrative, so for activity 1 (external entity sending
data) we show the output of that activity which is received by the system. For activities 17 and 18
(external entity receiving data) we show only the inputs required for the system to produce that output.

Process maps
A process map is a simple graphical representation of a business process, detailing the activities that
occur, the areas of the business responsible for completing the activities, the links between the different
areas of the business, and any decisions that need to be made as part of the process. Process mapping is
an important technique for documenting a system and represents an extremely useful tool that is regularly
employed by both consultants and auditors to understand a process and its operations.17 Jones and Lan-
caster note that as a result of this widespread usage, process mapping ‘has become a necessary element
in the accountant’s skill set and that accounting students would benefit by learning how to map a busi-
ness process’.18 It is also noted by Burns that, with process improvement as the new mantra of business,
process maps are a key component of process improvement as they are easy to understand and apply.19
Although many variants of process mapping exist under different names (for example, Business Process
Modelling Language or BPML), they are all based on the same fundamental principles described below.

Reading a process map

A process map is a high-level representation so it is much simpler than a DFD or systems flowchart. It
has a limited set of symbols and an easy-to-read format. The body of the process map consists of rec-
tangles, which represent the processes or activities that take place, and arrows connecting the processes,
which typically represent flows of documents or information among activities. These activities and flows
are placed in the map according to the division or functional area that performs the task. The different
organisational divisions or functional areas are represented by the horizontal rows that run across the
diagram. You may draw a comparison between the appearance of the map with the divisions and that of
lanes in a swimming pool.
Some rules to keep in mind when reading a process map20 are listed below and discussed in detail
with reference to figure 7.2, a process map drawn for the case in figure 7.1.
1. The functional areas appear down the left-hand side of the diagram.
2. The functional areas are separated with a solid line.

286 PART 2 Systems characteristics and considerations

3. The subfunctions are separated with a dashed line.
4. The standard symbol is a rectangle for a process or activity.
5. Process rectangles describe processes not documents.
6. The process map reads left to right and top to bottom.
Requesting

Sends Receive
dept

purchase purchase
requisition order
Purchasing

Checks Confirms Files matched

officer

Records Stamps & files Match?

Supplier? details & selects Confirm? purchase documents
requisition requisition
supplier order
Purchasing
supervisor

Approves Sign & send

Approve? purchase purchase
order order
Computer

Retrieves Creates Retrieves Print

Saves purchase
product & purchase purchase purchase
order
supplier details order order order
Supplier

Receive
purchase
order

FIGURE 7.2 Process map — reading a map

From the narrative in figure 7.1 we note that there are five different entities involved — the requesting
department, purchasing officer, purchasing supervisor, computer and supplier. In our process map, each
entity has its own lane. Also notice that the line separating the purchasing officer and the purchasing
supervisor is a dashed line — this tells us that both of these entities are from the same division of the
organisation, in this case, the purchasing department.
The arrows in the process map represent the movement of data or documents. From the process map
we can see the activity sequencing and linkages between activities and entities.
Each rectangle in the process map gives an indication of the activities or stages occurring within our
process. Although these are depicted at a higher level of abstraction in the process map, you should be
able to map the stages in the process map back to the activities in the process narrative table and the
original narrative in figure 7.1.
From the process map, we gain a good idea of who is involved in the process (i.e. the entities) and
some idea of what activities they perform (from the rectangles). However, we have very little indication
of how the activities are performed (e.g. Are the activities manual or computerised? Where does the data
come from when preparing a purchase order?).

Data flow diagrams

A data flow diagram (DFD) is a form of systems documentation that illustrates a system and the com-
ponents that make up the system, as well as the flows between these components. It allows the user of
the documentation to identify the entities involved in a system, the processes that take place within the

CHAPTER 7 Systems mapping and documentation 287

system, and the flows of data that occur between these entities and processes. There are three types of
DFDs: a context diagram, a physical DFD, and a logical DFD.
The context diagram is the simplest of the three, describing only what the system or process
of interest is and how it interacts with external entities (where the system gets its data from and
where the data ends up). A physical DFD identifies the people, places and things that perform
the activities in process (the internal entities), thus showing who is involved in the system and
the physical flows among these entities and the external entities. The focus in the physical DFD,
as the name would suggest, is very much on who or what is involved: the physical reality of the
system. A logical DFD conveys the processes that are performed within a system. Instead of identi-
fying who is involved in the system, the logical DFD shows what takes place inside the system, with
descriptions of the major processes that occur. Remember, the focus in the physical DFD is on the
entities that perform the activities. The focus in the logical DFD is on the logical activities and pro-
cesses that occur.
The remainder of this section takes you through the process of reading and preparing a context dia-
gram, logical DFD and physical DFD. Prior to the reading and preparation process, it is necessary to
understand the symbols used in DFDs.

Symbols
There are relatively few symbols used in preparing a DFD. These symbols are shown in figure 7.3. You
will notice that, in comparison to the systems flowchart, which will be discussed later, the symbols are
far less descriptive. This relative simplicity of DFDs is seen as one of their strengths, since it can facili-
tate communication between users and designers of a system, particularly when undertaking systems
development activities.21 The emphasis of the DFD is to show how data moves through a process and
how the data is provided, used and distributed by a system.22 Take some time now to familiarise yourself
with the DFD symbols.

External entity

System of interest (for a context diagram)

Internal entity (for a physical DFD)
Internal process (for a logical DFD)

Data flow

Data store

FIGURE 7.3 Data flow diagram symbols

288 PART 2 Systems characteristics and considerations

Context diagram
The context diagram provides a representation of the system of interest and the entities that pro-
vide inputs to, or receive outputs from, the system of interest. It is an overview of the data flow and
says nothing about what actually happens within the process. A context diagram is useful for clari-
fying the system’s boundaries and external interactions. An example of a context diagram is shown
in figure 7.4, which describes the simple ordering process for the organisation we looked at in the
previous examples.

Requesting
department
(1) Purchase request details

(18) Purchase order details

Purchase
process

(17) Purchase order details

Supplier

FIGURE 7.4 Context diagram — reading a DFD

The main features to observe in figure 7.4 are described below.

1. External entities. The two rectangles represent the two external entities. The external entities pro-
vide the inputs to the system of interest or receive outputs from the system of interest. They are not
involved in the actual information-processing activities within the system of interest. External enti-
ties only send or receive information to or from a system, represented by the flows to and from the
bubble, or system of interest.
  For example, the requesting department sends a purchase request and receives the purchase order,
but we do not know how the purchasing department actually creates the purchase order. Similarly, the
purchase order is sent to the supplier, but we do not know how the supplier uses the document after
receiving it. Linking back to our process narrative table in figure 7.2, those entities involved in only
sending or receiving data will be those that appear in the context diagram. Note that, even though the
requesting department is within the boundaries of the overall organisation, it is still an external entity.

CHAPTER 7 Systems mapping and documentation 289

 This is because it does not perform any information-processing activities within our current system of
interest. All it does is provide an input to the system.
2. System of interest. The bubble represents the system of interest. Anything that happens outside the
system of interest is not relevant to the DFDs. This reinforces the point made above about needing
to be clear on the boundaries of the system being documented. As a result, in context diagrams, as
well as in physical and logical DFDs, there cannot be flows between external entities. By definition,
external entities are not involved in the data processing of the system of interest and, therefore, any
flows between them are irrelevant for this system. Additionally, there can be only one system of
interest in a context diagram.
3. Level of detail. In the context diagram there is no detail about what actually occurs when pre-
paring the purchase order. This detail is essentially what happens within the bubble of the context
diagram. For example, it can be seen from the context diagram that the requesting department
sends a purchase request (which is the trigger or starting point for the purchasing process) and the
process generates a purchase order that is sent to both the supplier and the requesting department,
but we cannot see who prepared the order, or how the order was prepared. To find out who pre-
pared the purchase order we need to read the physical DFD. To find out how the purchase order
was prepared we need to read the logical DFD. This process of progressing from a higher level
document to lower levels, thus extracting more detail about who is involved and what gets done,
is referred to as decomposing (from the noun decomposition) or stepwise refinement,23 and is an
example of the ability of DFDs to be layered. This is a strength of DFDs as it enables increased
levels of detail to be shown in successive diagrams, rather than cluttering or over-detailing a single
diagram.

Physical data flow diagram

The physical DFD shows the ‘who’; the people, places and things involved in a system. Taking the
context diagram in figure 7.4, the question ‘Who created the purchase order?’ can be answered by
reference to the physical DFD in figure 7.5. Moving from the context diagram to the physical DFD is
an example of decomposing, or stepwise refinement. In this case, we are expanding the single bubble
of the purchase process in the context diagram in figure 7.4 to obtain details about the internal entities
within the process.
In contrast to the context diagram, the bubbles in figure 7.5 now represent the people, places and
things involved in data processing within the system of interest (i.e. the internal entities). So the physical
DFD can contain many more bubbles than just the bubble for the system of interest shown in the context
diagram. In this case, the physical DFD contains three bubbles: purchasing officer, computer, and pur-
chasing supervisor. These were the entities we identified earlier in our process narrative table as doing
more than just sending or receiving data. The numbering of the internal entities indicates the chrono-
logical order in which they take part in the process. The parallel lines indicate data stores or files. We
can see that two files are used by the purchasing officer, and the computer accesses four different data
files. Note that, while a physical DFD uses the same symbol for both paper and electronic data stores,
obviously paper data stores can be directly accessed only by a person and electronic data stores can be
directly accessed only by a computer.
From the physical DFD, we can see, for example, that the purchase requisition is sent to
the purchasing officer, who then keys the details into the computer and files the requisition in a
paper file. Do not be too concerned about the specific documents and file labels; they will become
clearer in looking at the different processes in later chapters. For now, you should be able to recog-
nise that the purchasing process, which is the bubble in the context diagram, has been ‘decomposed’
in the physical DFD to represent the different entities that are involved in the process. The flows
within the physical DFD refer to the document or data that is moving between entities. The number
in brackets on each flow also links each data flow back to the process narrative table we looked at in
table 7.2.

290 PART 2 Systems characteristics and considerations

 Purchase requisitions
awaiting order

Purchase requisition
(11)
(20) Finalised purchase
(1) (19) requisitions
1.0
Purchasing
officer
(22)
(2)
Requesting
department (8)
Copy 3 purchase order

(4)

Purchase order
Products

Ite
Pr

m
od

nu
Se

uc

mb
lec

ta

er
ted

nd
Co

su
su
py

pp
pp

lie
2p

lier
(3)

rd
urc

ata
(6)
has

Goo
eo

ds
qua (7)
rde

ntit 2.0
y&
r

(18) con Computer (3)

firm
(12) a tion
3.0 Confirmed pu
rchase order
Purchasing (14)
supervisor Approve and print
(17) Suppliers
Copy 1
(15) (9)
purchase order
3 purch
ase ord
er copie
s

Supplier
Purchase orders

(12)

FIGURE 7.5 Physical data flow diagram — reading a DFD

Logical data flow diagram

The logical DFD uses the same symbols as the physical DFD and context diagram. However, there
is one important distinction to make. Where the bubble in the physical DFD represents an entity that
is involved in the information-processing activities of the system, in a logical DFD the bubble rep-
resents the processes that occur within the system of interest. Referring to figure 7.5, as a basis for
comparison, bears out this distinction. An example of a logical DFD for our purchasing process is shown
in figure 7.6.
Compare the physical DFD in figure 7.5 to the logical DFD for the same system in figure 7.6. The
first difference you should have detected was that the bubbles contain different labels. This is because
the logical DFD is concerned with the activities that take place. As a result, the bubbles now depict the
major stages or activities that constitute the purchasing process.

CHAPTER 7 Systems mapping and documentation 291

 (11)
Products
1.0
Create Purchase request details
(3) Purchase
purchase
requisitions
order (1)
(3) awaiting order

(9) Requesting
(12) department (20)
Suppliers Purchase orders
(18) Purchase
order details
2.0
(15) Approve and Finalised
print purchase 3.0 purchase
Approved purchase
order Distribute requisitions
order details
purchase
(19)
orders
Purchase
order details 4.0 (22)
e Finalise
Purchas (17)
ails purchase
order det
Supplier requisition

FIGURE 7.6 Logical data flow diagram — reading a DFD

Take a moment to recall the definition of a logical DFD provided at the start of the chapter. The logical
DFD depicts the ‘how’; showing the processes that take place within a system, the flows between these pro-
cesses and how these processes interact with the external entities that provide inputs to, or receive outputs
from, the system of interest. Notice the difference to the physical DFD, which is more concerned with the
‘who’ (people, places and things) in the system. This difference is also why we have subtly different labels
in the two diagrams. As the bubbles in the logical DFD describe the ‘how’ we use a logical description of the
data that is flowing between the process bubbles, while in the physical DFD we describe physically what data
is flowing between the entities. For example: physically, flow 17 is a paper purchase order; logically, flow 17
is the data details contained in the purchase order. In the physical DFD, these labels refer to physical items
flowing through the system. In the logical DFD, the labels refer to the type of information being sent.
The steps in drawing the logical DFD will be discussed later in the chapter, including how to develop
the process bubbles. At this point, however, you should be comfortable with the idea that the logical
DFD describes the processes that happen within a system.
As a general guide, where the same data store is accessed in different stages and it cannot be linked
to both stages without complicating the flows, the data store may be repeated and shown as a three-sided
rectangle. This presentation format is used where the same data store appears more than once in
the diagram. You should use this repeated data store any time it will result in a clearer diagram; it is
much better to depict the data store twice than have data flows criss-crossing all over the page.
Also observe that, as in the physical DFD, the bubbles in the logical DFD are numbered. These
numbers represent the chronological order in which the processes occur. Notice how all the numbers in
the processes in figure 7.6 end in zero; for example, process 1.0 is ‘Create purchase order’, process 2.0
is ‘Approve and print purchase order’ and so on. This numbering provides an indication of the level of
the diagram. The diagram in figure 7.6 is a level 0 data flow diagram, which is the top level view of
each of the processes that occur. For each of the processes that appear in figure 7.6 you could go into
more detail, just as we did when we went from the context diagram to the logical DFD. For example,
expanding process 1.0 can be done through the preparation of a level 1 data flow diagram, which would
take the bubble for process 1.0 and expand it to illustrate the activities that are part of the level 0 process
labelled ‘Capture requisition’. This example is shown in figure 7.7.
Take a few moments to compare the level 0 (figure 7.6) and level 1 (figure 7.7) logical DFDs. All that
the level 1 diagram has done is to take the bubble labelled ‘1.0 Create purchase order’ and open it up to

292 PART 2 Systems characteristics and considerations

show the activities that comprise this first process. It should become apparent that the inputs and outputs
from process 1.0 must also appear in the level 1 diagram. Thus, in both diagrams we have three inputs
(the purchase request, the product details and the supplier details), three data stores (suppliers, products
and purchase orders), and two outflows (the purchase order data and the purchase request details, which
are eventually matched and filed in in process 4.0). The output flow from bubble 1.2 is the same as the
flow from process 1.0 in the level 0 DFD. This output is later used by process 4.0 when finalising the
purchase requisition.

Requesting (1)
department re Pur
qu ch Suppliers
es as
td e
et
ail
s
Products
1.0 (3)
Create
(3)
purchase
order
(9)

Confirmed purchase
Purchase orders order details

2.0
Stamp & file
(11)
requisition

Purchase
requisitions
awaiting order

FIGURE 7.7 Level 1 logical DFD decomposition

A final point to remember about the process of exploding the DFD is how the bubbles should be
numbered. For the level 0 diagram, the process numbers will always end in 0, so in figure 7.6 there are
processes 1.0, 2.0, 3.0 and 4.0. The numbering changes for a level 1 diagram, as shown in figure 7.7, and
can be explained as follows: The number before the decimal point indicates the level 0 process and the
number after the decimal point refers to the sequence of steps within the process. Should more detailed
descriptions of activities within a process be required, the level 1 diagram can be further expanded into
a level 2, level 3 or level 4 diagram. There is no limit to the levels, beyond the practicality of describing
the minute details of the system as the level becomes lower and lower.

Systems flowcharts
Conceptually, systems flowcharts represent a combination of the logical and physical DFDs, providing
details of how the processes are performed (logical perspective) as well as who the physical resources
are that perform them (physical perspective). The systems flowchart provides much more detail about
what actually happens within the system. Instead of just showing that incoming requisitions are recorded,
as the level 0 logical DFD does, the systems flowchart shows what is actually involved in recording the
incoming requisitions. The systems flowchart is also analogous to the process map, discussed earlier
in the chapter. It provides more detail of what actually happens within each process (or rectangle) that
appears on the process map. However, in contrast to the process map, where entities are listed down the

CHAPTER 7 Systems mapping and documentation 293

left-hand margin, the systems flowchart lists the entities across the top of the document. Each internal
entity has a separate column in the flowchart, and the number of columns in the flowchart equal the
number of internal entity bubbles in the physical DFD.
The other point to note is that, in comparison with the process map and the DFDs, systems flowcharts
have a much wider range of symbols that can be used, thus allowing more detail and insight for the user
of the documentation. Given this, it is crucial that, before proceeding too far in to this section, you spend
a moment familiarising yourself with the different symbols used in a systems flowchart.
Accountants need to be able to read and prepare flowcharts to competently describe the computerised pro-
cesses, manual operations, and inputs and outputs of an application system. Auditors use system flowcharts
to identify key control points in an accounting system’s internal control structure’.24 The highly detailed and
complex system flowchart is invaluable when conducting in-depth analysis of a system; however, given the
level of detail it is easy to lose sight of the big picture or overall purpose and flows of the system.
Systems flowchart symbols
Table 7.3 contains some of the symbols typically used in drawing a systems flowchart, with a brief
description of each symbol. Take some time now to learn these symbols, since the remainder of the
chapter will draw upon these in taking you through how to read and draw a systems flowchart.

TABLE 7.3 Flowchart symbols

Symbol Description

Start or stop, or an external entity — can depict either the beginning or end of
a process, or an external entity whenever they send or receive data from the
system of interest.
Data input — the keying in of data by a person using a keyboard. Only people
can use keyboards, so you would never use this symbol in a computer column.

Offline data input — for example, data gathered in a handheld barcode scanner
that is not immediately uploaded to the computer. Both people and computers can
use scanners, so you can use this symbol in either a person or a computer column.

Manual process — a process performed by a person, for example, counting how

many invoices are in a batch or attaching a label to a box. Only a person can perform
this type of activity, so you would never use this symbol in a computer column.

Computer process — a process performed by a computer, for example, data

extracted from a data store. Only a computer can perform this type of activity,
so you would never use this symbol in a person column.

A single paper document — computers can print documents and people can
read and use documents, so you can use this symbol in either a person or a
computer column.

Multiple (in this case three) documents — this could be three copies of the
same document or three different documents grouped together. For clarity,
each document contained in the group must be individually labelled.

Batch total — used to indicate when a batch (group) of documents has had some
calculation performed upon them, usually for control purposes. Examples include
totalling the totals of all the invoices contained in a batch (a batch total), or totalling
the invoice numbers of all the invoices contained in a batch (a hash total). The batch
total symbol should be shown as being attached to the documents in the batch.

294 PART 2 Systems characteristics and considerations

 Symbol Description
On-screen display — data displayed on a computer monitor. Computer
monitors can only be read by people, so you would never use this symbol in a
computer column.
An electronic data store — electronic data can only be accessed by a
computer, so you would never use this symbol in a person column.

A paper data store — the documents in the data store can be filed numerically,
alphabetically or chronologically; the filing order, if known, can be indicated
by an ‘N’, ‘A’ or ‘C as indicated. Paper documents can only be accessed by a
person, so you would never use this symbol in a computer column.
N

On-page connector — joins two different locations on the same page of the
A
flowchart; in this case joining two points on the same page both labelled ‘A’.
Off-page connector — joins two different locations on separate pages of the
flowchart, in this case joining point a on page 1 to point a on page 2. Note
2.a
that the notation on page 1 would read 2.a, and the notation on page 2 would
read 1.a.

Directional flow — used to indicate chronological sequence of the process

rather than always relating to flows of data.
A specific type of directional flow — used where data is being sent via a
telecommunications link, for example, over a phone line or via a broadband connection.
Annotation — used to provide additional descriptions or explanations within
the flowchart.

Physical goods or object moving through a process — for example, goods

delivered by a supplier or goods to be sent to a customer.

Reading a flowchart
There are two main features that you should be familiar with to be able to understand and read a systems
flowchart: the organisational division and the flowchart symbols. When reading flowcharts you will typi-
cally start at the top left-hand corner of the document and progress to the bottom right-hand corner.
The start of the flowchart is typically indicated by the use of a start/stop symbol or the presence of an
external entity symbol containing the name of the external entity.
You will also notice that a flowchart has several columns. Each column corresponds to an internal
entity that is a part of the process being documented. You will recall from our earlier discussion the con-
cept of an internal entity. Accordingly, one of the things that you should notice when you read a systems
flowchart and compare it with the physical data flow diagram is that the number of columns in the flow-
chart and the labelling of the columns in the flowchart are identical to the number of internal entities and
the labelling of internal entities in the physical DFD.
Each internal entity in the flowchart is separated by a solid line, and the name of the entity can be found
across the top of the page. Everything that appears within the column for an internal entity is a graphical rep-
resentation of the entity’s activities and how the entity carries out its activities within the system.
The flowchart symbols appear within the columns and show what is being done by each entity. Each
symbol conveys a different meaning, as shown in table 7.3. Not only do the symbols tell us what data
is used or what task is being performed, they also convey to us how a task is performed. For example,

CHAPTER 7 Systems mapping and documentation 295

the difference between a computer process and a manual process — an activity performed by a person
versus an activity performed by a computer — is evident from the different symbol for each. These
add to the semantic appeal of the flowchart, since they convey an added depth that is not present in the
DFDs. Now we become privy to a combined picture of not only what is done but also how it is done.
Refer back to table 7.3 for an explanation of the different symbols used in preparing a systems flow-
chart. After familiarising yourself with the symbols, examine figure 7.8 to help you understand how to
read a flowchart. In figure 7.8, person A keys some data into the system. The computer processes the
data and saves it to a data store. The document is then filed in alphabetical order.

Person A Computer

Document

Capture and save

Data input data

Display data
input Data store

Document

Document
file

FIGURE 7.8 A simple flowchart

Now look at figure 7.9. In figure 7.9, department A sends two copies of document A to person A.
Some data from document A is keyed in to the computer, which processes and saves the data. Person A
files copy 1 of document A in alphabetical order and sends copy 2 of document A to person B. When
person B receives document B from the customer, they match up document A (from department A) with
document B (from the customer). Some data from document B is keyed in to the computer. The com-
puter processes and saves the data, then displays the data to person B. Note that, logically, whenever you
key data into a computer you will be able to see it on the screen, so for completeness sake it is useful
to show a display linked to any keying in activity. Pragmatically, though, this can make your flowchart
cluttered and difficult to read, so a decision often needs to be made as to whether or not to document that

296 PART 2 Systems characteristics and considerations

a display will occur every time data are keyed in. One way of deciding when it is necessary to include
these displays is where the data display has a significant purpose in the process; for example, where a
person is required to review and confirm the accuracy of the data they have just input, or where the data
keyed in is a request for a particular piece of data to be displayed. The final activity in our flowchart
occurs when person B files the matched documents away in chronological order.

Person A Computer Person B

Dep’t A Capture & save a Customer

data

Doc A Copy 1
Document A
Doc A Copy 2 Document B
Copy 1

Match
Input data
documents
Data store
a
Doc A Copy 1 Matched Doc A
Doc A Copy 2 Copy 1
Matched Doc B

Entered
Doc A Capture and save
data Enter data

Display data

Matched Doc A
Matched Doc B Copy 1

Entered
Doc
A&B

FIGURE 7.9 A more complex flowchart

You should notice the use of on-page connectors in figure 7.9 (refer back to table 7.3). The connectors
have been used to show the movement of document A from person A to person B. Why use connectors
and not a line to connect person A and person B? Using connectors avoids the problem of lines going
all over the place, avoiding confusion and clutter in the diagram. As a general rule, if a flow goes to a
non-adjacent column, then on-page connectors should be used. Off-page connectors, which also appear
in the table of flowchart symbols, are used for a similar purpose.
To test your understanding of flowcharting symbols, take a few moments to read over figure 7.10
which is based on the narrative in figure 7.1.

CHAPTER 7 Systems mapping and documentation 297

 Purchasing officer Computer Purchasing supervisor

Requesting
department

(1)

Purchase
requisition
Supplier
(3)

Retrieves supplier
(2)
Item # & product

(3)

Product &
(4)
supplier details
Product

Checks
product (5)
description

Creates purchase
(6)
Selected supplier order

Purchase order (7)

Purchase order
Saves purchase
Goods qty & (8) (9)
order Purchase order
confirm
(12)

(12)

Stamps Reviews
Purchase Every Wednesday
purchase (10) Retrieves purch order (13)
requisition
requisition confirmed
(15) purchase orders
(11)

P req Save purchase

order (14) Approves and
awaiting
requests print
orders
(15)

(20) Purchase order 3

Purchase order 3
Purchase order 2 Purchase order 2
Purchase order 1 Purchase order 1
Signed P order 3 Matches P
req & P (21)
order

(22)
(19)
Signs
purchase (16)
a Finalised
order
purch
req

Requesting Signed P order 3

(18)
department
Signed P order 2 (19) a
Signed P order 1
Supplier (17)

FIGURE 7.10 Flowchart from narrative in figure 7.1

298 PART 2 Systems characteristics and considerations

7.6 Balancing a data flow diagram
LEARNING OBJECTIVE 7.6 Explain the concept of a balanced set of systems documentation.
An essential criterion for a set of systems documentation is consistency. Each of the context diagram,
physical DFD or logical DFD must provide us with a consistent representation of the external entities
involved in a system. Logically this makes sense as we are drawing the exact same system each time,
just adopting differing perspectives. As an example of this point, refer back to figure 7.4, the sample
context diagram. How many external entities appear in figure 7.4? How many flows from external enti-
ties appear in figure 7.4? How many data flows to external entities appear in figure 7.4?
Now refer to figures 7.5 and 7.6, the sample physical DFD and logical DFD for the process, and ask your-
self the same set of questions. If the set of systems documentation has been drawn correctly, the answers to
the above questions should be identical. Hopefully, you arrived at the answers shown in table 7.4.

TABLE 7.4 Balancing DFDs example

Diagram External entity Data sent Data received
Context diagram Requesting department Purchase request details Purchase order details
supplier — Purchase order details
Physical DFD Requesting department Purchase requisition Copy 2 Purchase order
supplier — Copy 1 Purchase order
Logical DFD Requesting department Purchase request details Purchase order details
supplier — Purchase order details

Do not underestimate the importance of the results in table 7.4. If the diagrams do not agree, your
systems documentation is incorrect. That is, because the three diagrams are drawn for the same system,
they should have the same external entities and flows in and out of the external entities. Diagrams (con-
text diagram, physical DFD and logical DFD) with the same external entities and flows to and from
these external entities are called balanced data flow diagrams.
Take a moment to observe the consistency, in terms of external entities and flows to and from external
entities, that exists between the context diagram, physical DFD and logical DFD in table 7.4. For the
diagrams to be balanced, we would expect to see the same external entities in each diagram and the same
number of inflows/outflows for each external entity. (Note that the label for the flows will change as we
move from the physical to the logical perspective.)

7.7 Drawing systems documentation

LEARNING OBJECTIVE 7.7 Generate different forms of systems documentation.
As we work through the process of preparing systems documentation we will use the case shown in
figure 7.11. As you read through the narrative, pay attention to three things.
1. Who are the people and things performing the activities? Focusing on this question will help identify
the entities that are involved in the process. In identifying entities, you should be looking for the men-
tion of specific people or things that are involved in the process. Examples could include the customer,
suppliers and specific people within the organisation (e.g. across the different functional areas). How-
ever, entities do not have to be restricted to people — items like a computer can also be included as they
will typically be involved in the sending, receiving and processing of data within a process.
2. What activities are being performed? Focusing on this question will help identify the activities that
are part of the process. In identifying the activities, you should pay particular attention to what the
entities are doing. As a tip, pay attention to the verbs in the process narrative. Examples of typical
activities performed by entities include:
•• preparing a document
•• entering data

CHAPTER 7 Systems mapping and documentation 299

 •• reconciling data or documents
•• approving a transaction or event
•• sorting documents
•• confirming details
•• filing documents
•• sending documents
•• receiving documents
•• batching documents
•• authorising an event or transaction.
This list is by no means exhaustive, but it should give you an idea of what to look for as you read
through a narrative for a process.
3. What are the inputs and outputs for each activity? In the previous step we identified the activities; we
now need to further decompose these activities to be aware of the inputs used and the outputs gener-
ated by the entity. For example, the activity ‘Prepare customer order form’ — in other words prepare
a record of what a customer wants to purchase — cannot be performed without data about what the
customer is purchasing. So our interest would be where this data comes from. Does it come from a
document? Does it come from a computer file? We identify these inputs to be clear about where the
data comes from within the process to ensure we are clear about what data is necessary for a par-
ticular activity to properly function.
  Also, pay attention to what outputs are generated by an activity. For example, if someone enters
data into the computer and the computer processes and saves it, where is the data saved to? What
documents are generated, by a computer or a person, as part of an activity? Be clear about these out-
puts and their destination.
The clearer you are about the answers to these three questions, the easier it is for you to prepare the
systems documentation. It is probably worthwhile, as a starting point, to highlight each of the entities,
activities, inputs and outputs as you read through the process narrative in figure 7.11.

Once the sales order is sent by the sales office to the warehouse clerk, the warehouse clerk manually
prepares a picking slip. This picking slip is used to pick the goods the customer has ordered and pack
them into a box. After all the goods have been packed, the items on the picking slip are initialled to indi-
cate that the correct quantities have been taken from the shelves. The goods, sales order and picking
slip are then forwarded to the dispatch administrator who compares the details of the picking slip to
the items in the box. If there is any discrepancy between the packed goods and the documentation, the
dispatch administrator will resolve the difference.
Once the goods and the documentation have been checked, the dispatch administrator keys the
sales order number into the computer, and the computer updates the sales order status to ‘Goods
packed’. The computer then extracts and displays a list of approved couriers from the ‘Approved
carrier’ data store. The dispatch administrator selects a courier from the list and clicks on ‘Confirm’.
The computer then adds the courier details to the sales order, updates the status of the sales order
to ‘Courier confirmed’, and displays the details on the computer screen. The dispatch administrator
reviews the details on the screen and clicks ‘Accept details’. The computer then creates a shipping
notice, which is stored in the ‘Shipping notice’ file, and a bill of lading, which is stored in the ‘Bill of
lading’ file.
The computer prints two copies of the shipping notice and one copy of the bill of lading on the dis-
patch administrator’s local printer. The dispatch administrator reviews the bill of lading and the shipping
notice and attaches them to the packed goods, which are then placed in the shipping area. The sales
order and picking slip are matched to the relevant shipping notice and sent to accounts receivable.
Once received by accounts receivable, the sales order, picking slip and shipping notice are matched
with the customer’s original purchase order (stored in the ‘Customer purchase orders awaiting delivery’
file) and filed by shipment date in the ‘Sales orders to be invoiced’ file.

FIGURE 7.11 Narrative for drawing systems documentation

300 PART 2 Systems characteristics and considerations

 Once you are familiar with the case narrative and have considered the three questions of who/what is
involved, what activities occur, and what inputs and outputs are involved, you are ready to complete the
first step in the systems documentation process — the process narrative table.

Analysing the case

The first step in preparing the systems documentation is to complete the process narrative table.
As a starting point for preparing the process narrative table, make a list of the entities that are involved
in the case in figure 7.11. If you have read through the case, you should have identified the following
entities:
•• sales office
•• warehouse clerk
•• dispatch administrator
•• computer
•• shipping area
•• accounts receivable.
In preparing the process narrative table it will become apparent whether an entity is internal or external,
since you will need to work out whether the entity is engaged only in sending and receiving data or
whether it also performs information-processing activities. Having identified the entities, the next step is
to work through the narrative identifying each activity and placing it in the process narrative table, speci­
fying the entity and inputs and outputs associated with each activity. You will complete the table based
on the order in which the entries are mentioned in the case narrative. The process narrative table for the
case in figure 7.11 is shown in table 7.5.

TABLE 7.5 Completed process narrative table

No. Entity Process/activity Inputs required Outputs produced

1 Sales office Sends sales order to Sales order

warehouse

2 Warehouse clerk Prepares picking slip Sales order Picking slip

3 Warehouse clerk Picks and packs goods Picking slip Packed goods

4 Warehouse clerk Initials picking slip Picking slip Initialled picking slip

5 Warehouse clerk Forwards goods, sales order Goods, sales order and Despatched packed goods,
and picking slip to dispatch picking slip sales order and picking slip
administrator

6 Dispatch administrator Compares packed goods to Packed goods details Checked packed goods
picking slip and sales order details

7 Dispatch administrator Enters sales order number Sales order Entered sales order number
into computer

8 Computer Updates sales order status Entered sales order number Updated sales order ‘Goods
packed’

9 Computer Extracts and displays list of Entered sales order number List of approved couriers
approved couriers

(continued)

CHAPTER 7 Systems mapping and documentation 301

TABLE 7.5 (continued)

No. Entity Process/activity Inputs required Outputs produced

10 Dispatch administrator Selects a courier List of approved couriers Selected courier

11 Dispatch administrator Enters courier confirmation Selected courier Confirmed courier

12 Computer Adds courier details to sales Confirmed courier Updated sales order
orders and updates status to
‘Courier confirmed’

13 Computer Displays sales order details Updated sales order Displayed sales order

14 Dispatch administrator Reviews details Displayed sales order Reviewed sales order

15 Dispatch administrator Inputs sales order Reviewed sales order Accepted sales order
acceptance

16 Computer Creates and saves shipping Accepted sales order Saved shipping notice
notice

17 Computer Creates and saves bill of Accepted sales order Saved bill of lading
lading

18 Computer Prints 2 copies of shipping Saved shipping notice and bill Printed shipping notices and
notice and 1 copy of bill of of lading bill of lading
lading

19 Dispatch administrator Checks and attaches bill of Shipping notice, bill of lading, Checked goods with bill of
lading and shipping notice to and goods lading and shipping notice
goods

20 Dispatch administrator Places goods and attached Checked goods with bill of
documents in shipping area lading and shipping notice

21 Dispatch administrator Matches sales order, picking Sales order, picking slip and Matched sales order, picking
slip and shipping notice shipping notice slip and shipping notice

22 Dispatch administrator Sends matched documents Matched sales order, picking Despatched matched
to accounts receivable slip and shipping notice documents

23 Accounts receivable Retrieves customer’s Matched sales order, picking Relevant purchase order
purchase order slip and shipping notice

24 Accounts receivable Matches customer purchase Sales order, picking slip, Matched sales order, picking
order to sales order, picking shipping notice and purchase slip, shipping notice and
slip and shipping notice order purchase order

25 Accounts receivable Files matched documents by Matched sales order, picking Filed matched sales order,
shipment date slip, shipping notice and picking slip, shipping notice
purchase order and purchase order

In preparing the table you should pay particular attention to the specific activities that occur and the
order in which they occur. The more precise you can be about the activities at this stage, the clearer your
systems documentation.
Note that inputs and outputs are specified in relation to the specific activity that is being documented
in each row of the table. As a result, where an input or output is used in more than one activity, it will

302 PART 2 Systems characteristics and considerations

appear more than once in the table. An example of this is the sales order, which is involved in multiple
activities. Note that in this process we have both a sales order document (paper) and sales order data
(electronic). The creation and printing of the sales order document is outside the boundary of our system
of interest. The sales order document is sent from the sales department to the warehouse clerk who uses
it when preparing the picking slip. The sales order subsequently is used also by the dispatch adminis-
trator when verifying the packed goods, obtaining approved courier details and creating the shipping
documentation. Finally, the sales order is sent through to accounts receivable, who match it to the orig-
inal customer purchase order for use when invoicing the customer, which is outside the boundary of our
system of interest.
The electronic sales data is stored in the data storage within a computer, so it does not physically
move between entities in the same way as paper; however, its status and content do change throughout
the process. The sales data is produced originally by the sales office when they record a new sale; this is
outside the scope of our system of interest. The sales order data is updated twice during the process. The
dispatch administrator updates the status of the sale firstly to ‘goods packed’ after verifying the packing
of the goods (flow 8) and later to ‘courier confirmed’ after selecting a courier in flow 12. Flow 12 also
sees some additional data added to the original sales order data. The sales order data now includes the
details of the specific courier who will be delivering the goods.
Think for a moment about why status updating for electronic data matters. Remember a pro-
cess runs (or executes) every time a transaction is triggered, in this case every time a new sales
order is received in the warehouse, the pick, pack and ship process is triggered and runs. There
will be a number (sometimes a very large number) of simultaneous instantiations of the process
occurring at any point in time. Imagine a customer calls up and enquires about the progress of
their order. Depending on where exactly in the process their order is when they enquire, the status
data will reflect that time point. For example, if a customer enquired after the sales order had been
printed and sent to the warehouse but before the goods had been packed and checked, the infor-
mation you would give the customer based on the sales order status is that the sales order has been
‘sent to warehouse’ and will soon be packed. If that customer enquired after the goods had been
packed and checked but before the courier had been assigned, the answer would be ‘your goods
have been packed’ and we will shortly be assigning a courier. Updating the status of transactions
during the process is vitally important for providing timely and accurate feedback to customers. In
addition, being able to identify the time between changes of status, as well as volumes of transactions
with a given status at particular points in time, provides valuable process performance and planning
data.
A final aspect to notice is the specification of computer activities. For example, look at the choice of
the courier by the dispatch administrator. After the details of the packed goods have been verified, the
computer retrieves a list of couriers from an existing data store. In order for the dispatch administrator
to be able to select a supplier from the list, the computer must first retrieve the data and then display it
on the screen. This is evident in activities 9, 10, 11 and 12, where the list is extracted and displayed, a
specific courier is selected and entered, and then the sales order data is subsequently updated to incor-
porate the details of the selected courier. In some cases this will be made explicit in the narrative. In
other cases it should be something to pay attention to. If the computer displays something on the screen,
or if a person selects something from a list displayed on the screen, always look for an indication of
where the computer got the underlying data from.

Preparing a process map

Preparing a process map is relatively simple. You need to be familiar with the case or process that you
are mapping. The shipping of goods process described in figure 7.11 will again be used. You should also
refer back to the process narrative table that was prepared in table 7.5. For the exercises in this chapter,
you will be provided with a narrative for a system and will be required to draw a process map based on

CHAPTER 7 Systems mapping and documentation 303

the narrative. The task of data gathering has essentially been performed for you and is represented in
the narrative. In a real-world organisation, the task of gaining an understanding of the business process
could be far more complex and time consuming and involve activities that include data gathering, map
structuring, mapping documentation and feedback interaction.25 These four stages are discussed briefly
in figure 7.12.

1. Data gathering
Data gathering involves the map preparer gaining an understanding and knowledge of the process
from any existing documentation that may exist. Once familiar with the process, the map preparer
will then interview ‘experts’ in the process and consider their comments and observations.
2. Map structuring
An early draft of the process map will then be prepared, based on the interviews with the process
experts. This is a preliminary diagram that assimilates the information gathered from the different
process experts during the interview stage.
3. Map documentation
A written description of the process’s operation will be prepared, along with a final version of the
process map.
4. Feedback interaction
The process maps will then be distributed to different participants for comment. Any comments can
be taken from readers of the documentation and can, in some instances, lead to further interviews
and group meetings to discuss the process maps.26

FIGURE 7.12 Process mapping stages

Step 1: Identify entities and divisions

Once you understand the process and how it operates (for your purpose, this means once
you have read and understood the narrative), you are ready to commence preparing the pro-
cess map. The first step is to compile a chronological list of the entities and their respective
activities in the process. As described above, an entity can be any person, place or thing involved,
including people and computers. Remember, data processing means using or transforming infor-
mation in some way. Sending and receiving documents does not constitute an information-processing
activity.
Reviewing the process narrative table in figure 7.5, which breaks down the shipping goods process by
entity, activity, input and output, provides us with the entities and their order of appearance within the
process. As a result, we are now ready to prepare the lanes for each entity.

Step 2: Draw the lanes for each division

Based on the identified entities, you are now ready to commence drawing the diagram. Start by drawing
a large rectangle. Divide this rectangle up, using solid horizontal lines. If you have four entities identi-
fied in the previous step, then the rectangle will need to be divided up into four parts; five entities will
require five parts, and so on. Once the ‘swim lanes’ have been created, label them down the left-hand
side with the entity name.

Step 3: Indicate any subfunctions

Next, if you have two different entities working in the same division involved in the process, you
need to represent this in the process map. Do you remember the rule that a dashed line is used to
separate two different people from the same division? Based on this rule, where you have a div-
ision with more than one entity involved, break the division up using a broken horizontal line, so
that there is a swim lane for each person. In this case both the warehouse clerk and the dispatch

304 PART 2 Systems characteristics and considerations

administrator could be viewed as being in the same division (inventory control) and as a result they
are separated by a dashed line.
Having progressed this far, you should now have something representing a swimming pool with the
lane ropes in place, and each lane should bear the name of the entity involved. An example of the pro-
cess map up to this point is contained in figure 7.13.
Sales office
Warehouse
clerk
administrator
Dispatch
Computer
receivable
Accounts
Shipping area

FIGURE 7.13 The empty swim lanes

Step 4: Illustrate the activities of each entity

In this step, the task is to fill in the lanes for each entity involved: that is, provide a representation of the
tasks performed, how the tasks link up with one another, and the documents and information that flow
among the entities.
Completing this task requires a synthesis of the details in our process narrative. The aim is to pro-
vide an overview of the major steps that occur but not to put so much detail in the document that it
becomes unreadable. Essentially, you are trying to summarise the process into the major stages that
it follows.

CHAPTER 7 Systems mapping and documentation 305

 If we were to review the process narrative table in table 7.5, we could deduce that the following major
stages occurred (table 7.6), with the predominant entity in the stage shown in brackets.

TABLE 7.6 Major stages in process for inclusion in the process map

1. Sales order sent to warehouse (sales office)

2. Goods packed (warehouse clerk)

3. Goods checked (dispatch administrator)

4. Courier details retrieved (computer)

5. A courier assigned (dispatch administrator)

6. Shipping documentation prepared (computer)

7. Goods shipped (dispatch administrator)

8. Shipping documents sent to accounts receivable (dispatch administrator)

9. Shipping documents matched and filed (accounts receivable).

Note that this is a very high level summary of what happens in the process. Effectively we
are summarising the process narrative table into the major stages that are followed in the shipping
goods process. Each of these processes will be represented by one or more rectangles. In some
instances, we note that decisions need to be made. For example, the dispatch officer must compare
whether the goods in the box match the goods listed on the picking slip. If they do agree, the process
can continue. If they do not agree, the normal operation of the process must be stopped so that the
discrepancy can be resolved. This decision point is represented by a diamond in our process map.
The flows between the stages, be they documents or data, are shown by the arrows that connect each
stage. The final stage is to populate the empty swim lanes in figure 7.13 with the stages identified
above.
It should be apparent, at this point, that the completion of the process narrative table was a signifi-
cant step towards completing the process map, since it details who the entities are that are involved
in the process and the processes that each performs, as well as what each sends and receives. In
addition, the summary table we created above further provides a structure for putting the process map
together, since it clarifies the major stages of the process. It is now possible to fill in the empty swim
lanes by drawing a rectangle for each process and an arrow labelled with the appropriate data flows.
Attempt to complete the swim lanes in figure 7.13 before looking at the completed process map in
figure 7.14. If you have any differences or discrepancies between your version and the version in
figure 7.14, you may wish to first go back and check your completed table against the process narra-
tive table. How you described process stages and the level of granularity in your stages will have
an effect on the appearance of your process map. However, also keep in mind that the description
of the major stages is somewhat subjective — so your answer may be just as correct as the one we
present, with the difference being the way you have broken up and described the major stages. As
Burns notes, ‘There is no such thing as a perfect swim lane. If you described a business process to
100 people all trained in swim lane you would get 100 different flowcharts. You’re only looking for a
reasonable approximation’27 of the process being mapped.

306 PART 2 Systems characteristics and considerations

Sales office
Sales order
sent

Warehouse
clerk

Stock Goods
available? packed
administrator
Dispatch

Goods Correct Which Courier Goods Documents Documents

checked goods? courier? assigned shipped match? sent
Computer

Shipping
Courier details documents
created
Shipping

Goods for
area

shipping
received
receivable
Accounts

Documents Matched
match? documents filed

FIGURE 7.14 Completed process map

Preparing data flow diagrams

We will now work through the process of preparing the DFDs. Again the reference will be our narrative
and our process narrative table in figure 7.11 and table 7.5, respectively.

Drawing a context diagram

Drawing the context diagram requires you to be clear on two main aspects of the system. The first is
what system or process you are documenting. The following refers to the picking, packing and shipping
of goods process. The narrative for this process was illustrated in figure 7.11, and was used in the prep-
aration of the process map. Clearly defining the system of interest is crucial for correct documentation
because it sets the scope for what the logical and physical DFD will cover. If you think you need to
include more than one bubble in a context diagram, then you are not totally clear on what the system of
interest is. Once you have decided what process or system is being documented, you have the bubble for
your context diagram.
The next step is to work out what the external entities are that receive outputs from or provide inputs to the
system of interest. If you have completed the process narrative table from the preparation of the process map,
this is a relatively simple exercise. One of the critical things to remember when classifying entities is that
external entities are not involved in the actual information-processing activities of the system — they simply
send inputs or receive outputs. A quick way to determine which entities are external entities is to have a look

CHAPTER 7 Systems mapping and documentation 307

at the input and output columns of table 7.5 prepared for the process map. If these are the only columns that
are filled for an entity, the entity performs no processing and is therefore an external entity. Based on this
criterion, re-examine table 7.5 and prepare a list of the external entities.
Once you have defined your system of interest as well as your external entities, the final stage is to identify
the data flows that originate from or end at the external entity. Again, depending on how much detail you used
in completing the process narrative table, you should be able to identify these flows from your table. These
flows are then drawn in as data flow arrows that connect the external entity and the system of interest.
Before looking at figure 7.16, make an attempt at drawing the context diagram on your own.
Remember the symbols used in the context diagram — a bubble for the system of interest, a rectangle
for the external entities, and arrows for the inputs and outputs relating to the system of interest. A sum-
mary of the main steps in preparing the context diagram is contained in figure 7.15. Compare your result
to that in figure 7.16 and reconcile any differences.

1. Identify the system of interest. Draw a bubble and label it to represent the system of interest.
2. Identify the external entities (those that do not perform information-processing activities). Draw and
label a rectangle for each external entity.
3. Identify any data flows between the external entities and the system of interest.
4. Draw in the data flows connecting the external entities and system of interest and label them
accordingly.

FIGURE 7.15 Summary of steps in drawing a context diagram

Sales office

(1) Sales order details

Pick, pack &

ship goods

(20) Shipped goods details

Shipping
area

FIGURE 7.16 Completed context diagram

Drawing a physical data flow diagram

A physical DFD is a graphical representation of the people, places and things involved in a system. The
preparation of the DFD builds from where the context diagram left off. Indeed, having the context dia-
gram prepared is a good starting point for the physical DFD because the context diagram contains the
external entities. All that is needed when preparing the physical DFD is to expand the process bubble
of the context diagram, adding more detail to it, so that it shows who the people, places and things are
that perform information-processing activities within the system of interest. These will be the internal
entities.

308 PART 2 Systems characteristics and considerations

 Again, a good starting point for determining who the internal entities are for the system is to refer
back to the process narrative table. In the case in table 7.5, the external entities are the customer and the
sales office, since all they do is send or receive data. These external entities were also identified when
we previously prepared our context diagram. The remaining entities are those that perform at least one
information-processing activity. These entities will all appear in the physical data flow diagram, rep-
resented by bubbles, and labelled with their name and a number, to represent the order in which they
appear in the process.
To draw these entities into the physical data flow diagram you should initially work out the order in
which they appear in the system. This allows the entities in the diagram to be numbered. For example,
the sales office sends the sales order to the warehouse clerk. Therefore, the warehouse clerk is the first
of the internal entities to be involved in the process and would be numbered 1.0. The process is repeated
for all the entities. You should have as many numbers as there are internal entities. For this system there
are four internal entities — can you list them?
Once you have numbered the internal entities, you can then place them on the data flow diagram. As
mentioned above, keep in mind that documentation conventions suggest that your diagram should com-
mence in the top left-hand corner and progress left to right and top to bottom, thus ending in approxi-
mately the bottom right corner of the page. However, this is a guideline that, while encouraged for ease
of reading the diagram, should not be seen as an unbreakable law.
With your external entities already identified from the context diagram and your internal entities
drawn in, the next step is to identify the data flows between the entities. This information is readily avail-
able from the process narrative table. Data stores also need to be drawn in, for example, when a docu-
ment gets filed away. One thing to note when preparing the diagram is that, in the table, both sending
and receiving were listed. For example, the table notes that the sales office sends the sales order and
the warehouse clerk receives the sales order. This was done to clearly identify the flows each entity is
involved in. When drawing the diagram only one of these flows needs to be included, because they are
the same data flow. Be careful to avoid drawing in duplicate flows. As the flows are drawn in, they will
be labelled with the line number from the process narrative and a description of the data that is being
sent or received. This description will typically be the document type for paper documents and the data
type for electronic data.
Care must also be taken where there are many people performing the same role. For example, it may
be the case that there are five warehouse clerks all performing the same function. Does this mean that
five bubbles are needed in the physical data flow diagram? No. In this case you need to draw the entity
only once and will need only one bubble to represent the five clerks.
A summary of the steps in preparing a physical DFD is contained in figure 7.17. A physical DFD
for the sample process is contained in figure 7.18. You should be able to obtain a similar diagram by
following the steps in figure 7.17 and the previous discussion.

1. Identify the external entities (those that do not perform information-processing activities). Draw and
label a rectangle for each external entity.
2. Identify the internal entities and list them in the order they appear in the system’s operation.
3. Draw in a bubble for each internal entity and label and number the bubbles accordingly.
4. Identify any data flows between the external entities and internal entities. Draw in these flows and
label the data flow arrows.
5. Identify the data flows between the internal entities. Draw in these data flows between internal enti-
ties and label the arrows with the physical document/information that is being sent or received.
6. Identify any data stores that are accessed to get data or to store data as part of the process. These
may be paper based or electronic. Draw these data stores in and link them to the entity that accesses
them by including data flow arrows.

FIGURE 7.17 Drawing a physical DFD

CHAPTER 7 Systems mapping and documentation 309

 1.0
Sales office (1) Warehouse
Sales order
clerk
Shipping
(20) area
(5)

no g
e
Sales order,

ng in
tic
pi ad
picking slip

ip f l
sh ill o
B
er #
s ord 2.0
Sale

&
Dispatch
ers
(7) uri administrator (22)
co
v ed
pro r (13) Sales order,
Ap
Sales order r de picking slip &
so
le ce shipping notice
(9) Sa tan (18)
(8) cep
ac tice
der no ing
or g
n lad
(12) 3.0 les pi
Sa h ip ll of l
Computer S bi va
(15) & p ro 4.0
p
ra Accounts
(9) u rie
(11) Co (23)
receivable

(16)
Approved (17)
Customer PO (25)
couriers awaiting
delivery
Sales orders to
Bill of lading
be invoiced
Shipping notice

FIGURE 7.18 Completed physical data flow diagram

Drawing a logical data flow diagram

The example logical DFD uses the same shipping goods case as the other diagrams. Having seen how to
read a logical DFD, you should be reasonably comfortable with the idea that the logical diagram tells us
the activities that occur within a system or process. Therefore, in preparing a logical DFD, the different
activities that occur within the system need to be determined. Once again, a good starting point for this
is the process narrative table in table 7.5.
Determine information-processing activities
Look at table 7.5 once again. In preparing the logical DFD, the major concern is with grouping the pro-
cessing activities that are listed in the ‘Process/activity’ column. The external entities, along with the
inputs they provide and the outputs they receive, were defined in preparing the context diagram. The
challenge when preparing the logical DFD is to show how these inputs and outputs fit into the activities
performed within the system.
As a starting point, from the list of activities that are presented in table 7.5, identify those entities
that perform information processing. Next, highlight the information-processing activities. Note in
table 7.5 that the sales office in activity 1 and the shipping area in activity 20 are involved only in
sending and receiving activities (i.e. they are external entities). Any activities performed by internal
entities that are just sending or receiving should also be noted. This is because, when creating the

310 PART 2 Systems characteristics and considerations

logical DFD, there is a need to focus only on the information-processing activities that are performed
by the internal entities.
Group activities logically
The information-processing activities that remain in table 7.5 need to be grouped so that they are logi-
cally representative of the system of interest. This grouping process can be subjective, with the group-
ings arrived at by one person being potentially different from the groupings of another. Thus, while there
is only one correct diagram for a physical DFD, there can be many correct solutions for a logical DFD.
However, this is subject to the overriding disclaimer that the grouping of your activities must make
sense — activities cannot just be grouped at random!
This raises the question of how to go about grouping the information-processing activities.
A common approach is to group activities that take place at the same time. With the time-based
approach, it may be a useful exercise to make sure that your process narrative table is sequenced
chronologically, because this makes it much easier to group activities based on order of performance
within the process. This is also where it is important to fully understand the details of the system or
the system narrative that you are working on. Hopefully, you are starting to see the benefit of pre-
paring the process narrative table as part of the documentation process, because it allows the case to
be broken down into a chronological series of events. Narratives for systems do not always do this;
so, as system documentation preparers, you should take some time to fully understand a narrative and
the sequence of events before putting pen to paper. This approach will make the whole process easier
in the long run.
To group the activities in table 7.5 means looking for activities that occur at the same time and
contribute towards the same general aim or underlying objective. Cast your eye over the list of
­information-processing activities shown in table 7.5 and see whether you can group them in some
logical manner. Are there some activities that logically go together? Are there activities that occur
at the same time and contribute to the same underlying goal of a particular stage of the process? If
so, group them together. A suggested template for doing this is shown below. The first column refers
to the position of the stage in the process, the second is a brief description of what happens at that
stage and the third column is for the activities from the process narrative table that are part of the
stage.

Stage Description Related activities

A suggested table for the shipping goods process is shown in table 7.7.

TABLE 7.7 Grouping of information-processing activities

Process Description Related activities

1.0 Pick and pack goods 1–5

2.0 Update sales order 6–8

3.0 Assign courier 9–13

4.0 Ship goods 14–20

5.0 Match to purchase order 21–25

The information-processing activities identified in table 7.5 have been grouped into five processes/
stages. Note that each process is numbered and, because a level 0 DFD is being prepared, all the process
numbers end in 0. The numbering of the processes indicates the order they are performed in.

CHAPTER 7 Systems mapping and documentation 311

 A brief explanation of these five process groupings follows.
1. Process 1.0 Pick and pack goods. This is the stage where the sales order is received and the goods are
retrieved from the shelf and packed, with the picking slip being prepared, annotated and matched to
the sales order. Activities 2, 3 and 4 all relate to this process of packing the goods the customer has
ordered.
2. Process 2.0 Update sales order. Using the data about the packed goods, the dispatch administrator
will ensure that what is in the box matches what is on the documentation. To do this, the goods need
to have been packed (process 1.0) and data is now required (from the documentation). Once the dis-
patch administrator has checked the goods, they update the sales order status to reflect that the goods
have been packed.
3. Process 3.0 Assign courier. Once the goods have been checked, a courier is selected and
assigned. The computer provides a list of pre-approved couriers and a suitable courier is chosen
by the dispatch administrator. The sales order status is updated to show that a courier has been
selected.
4. Process 4.0 Ship the goods. Once the goods are packed and a courier has been selected, the docu-
mentation that relates to the sending of the goods — the bill of lading and the shipping notice — can
be prepared. This stage requires all of the preceding stages to have been completed (i.e. know what is
being sent and who the courier is). It involves the creation of source documents and several computer
actions to save data and print reports. Finally, the goods and documentation are sent to the shipping
area.
5. Process 5.0 Match to purchase order. Before accounts receivable is able to arrange for an invoice to
be prepared and for the ledgers to be updated to reflect the goods sold, what was sent needs to be
matched with what the customer ordered. Accounts receivable therefore needs data about the goods
sent (from process 4.0) to reconcile against the purchase order received from the customer at a dif-
ferent time (outside this process of shipping goods).
You should notice from these groupings that the emphasis is on activities that occur at roughly the
same time and contribute to a specific goal or stage of the process, be it packing the goods, checking the
goods or recording data about shipments. There is a clear chronology from process 1.0 to 5.0 as well as
necessary data flows from process 1.0 to subsequent processes.
Having identified the processes that will appear in the logical data flow diagram, the five process
bubbles can be drawn. Again, they should run left to right and top to bottom on your page. Do not forget
to include the process numbers within the bubbles and ensure that the processes are numbered correctly
(e.g. a level 0 DFD should have process numbers all ending in 0). Once the processes are included in the
logical diagram, they need to be linked. So you need to go back to table 7.5 and look at the data flows
that occur among the processes. Essentially, it is a question of asking what data is needed for the next
stage to occur and what data does the stage generate for subsequent stages. These flows among processes
can then be drawn onto the diagram.
The diagrams prepared to this point represent how the system would function in normal operations,
assuming no errors or abnormalities occur. An example of this could be activities 6 or 24, where docu-
ments are being reconciled or data checked. The assumption is that the documents and data will agree
and there will be no errors. If, for example, accounts receivable discover that the purchase order and
shipping notice do not agree, they would need to go back through the process to work out why. This is
an example of a routine that is performed when the system does not function as is normally expected:
an error routine. This flow backwards is not shown in the level 0 DFDs. That is, you cannot have flows
from a higher numbered process to a lower numbered process. (If a process is working as expected, why
else would you send an item back to an earlier stage?) If an error routine needs to be documented, then
it can be done in a separate DFD. System documentation convention dictates that error routines and
abnormal procedures are not shown on the main level 0 DFD. Figure 7.19 shows the complete logical
DFD for the shipping goods process. Make sure you have attempted to draw your own logical DFD
before looking at figure 7.19.

312 PART 2 Systems characteristics and considerations

Sales office (1)

Sales
order details 1.0
Pick & pack (5)
goods Goods
details

2.0
Updates
sales order
(8)
Approved
Updated sales
couriers
order details

Sales order 3.0 (9) Shipping

Assigns
notice
courier
(12)

(16)

Reviewed sales
4.0
order details (17)
Ships goods

Bill of lading
s
ood
dg
(20) hippe tails Shipped sales
S de order details
Shipping
area
5.0
Matches to
(23) purchase (25)
order
Customer PO
awaiting Sales orders to
delivery be invoiced

FIGURE 7.19 Completed logical data flow diagram

Figure 7.20 is a summary of the steps to follow when preparing a logical DFD.

1. Identify the external entities (those that do not perform information-processing activities). Draw and
label a rectangle for each external entity.
2. From the table with the division, entities and activities (sends or receives and processes performed),
eliminate any entities that just send or receive items and any activities that are just send or receive.
3. Group the remaining information-processing activities based on the underlying process they perform.
A common method is to group processes that occur at the same time.

FIGURE 7.20 Drawing a logical data flow diagram (continued)

CHAPTER 7 Systems mapping and documentation 313

 FIGURE 7.20 (continued)

4. Number and label the underlying process performed by the group of activities. Draw a bubble for
each group of activities.
5. Identify any data flows between the external entities and the processes. Draw in these flows and
label the data flow arrows.
6. Identify the data flows between the processes. Draw in these data flows between processes and
label the arrows with a logical description of the data that is being sent or received.
7. Identify any data stores that are accessed to get data or to store data as part of the process. These
may be paper based or electronic. Draw these data stores in and link them to the process that
accesses them by including data flow arrows.
8. Ensure your logical DFD balances with your physical data flow diagram and context diagram.

Drawing a systems flowchart

For the demonstration of drawing a systems flowchart, again the picking, packing and shipping goods
process will be used. By now you should be familiar with the details of the system. Also refer to the
process narrative table in figure 7.5. This description draws on the examples and concepts of Lehman28
and Smith and Smith.29
Understand the system
The first stage in drawing a flowchart is to be familiar with the system that is going to be depicted. You
can gain this familiarity in several ways, but at the early stages of drawing flowcharts one of the best
approaches is to break the system up based on the entities, processes, and inputs and outputs. List these
entities and processes in a process narrative table based on the order in which the processes occur. You
may want to redraw the table now for yourself or refer to table 7.5 for a refresher.
Represent the entities
The next step is to represent the entities that are involved in the case within the flowchart. This is similar
to the creation of the swim lanes in the process map but for one critical difference: in the process map
the entities are listed down the left-hand side of the diagram, but in the systems flowchart they are listed
across the top. So, while the lanes of the process map run horizontally, the lanes on the system flowchart
will run vertically. Divide your page up now, based on the internal entities we have previously identified
(warehouse clerk, dispatch administrator, computer and accounts receivable). You should end up with
something similar to figure 7.21.

Warehouse Computer Dispatch Accounts

clerk administrator receivable

FIGURE 7.21 Representing the entities within a systems flowchart

Complete each entity’s activities

The next step is to fill in the columns for each of the entities. This is done using the flowchart symbols
introduced in table 7.3. Before starting to draw, take some time to recall some of the symbols used in
flowcharting.

314 PART 2 Systems characteristics and considerations

 Within each column of the flowchart we need to depict the inputs and outputs, and the activities
performed. The task is then to represent what happens using the flowchart symbols. See if you can
fill in the columns of your flowchart with the correct symbols and flows. A few simple rules to
keep in mind as you do this are provided in figure 7.22, which shows a list of rules and pointers for
flowcharting.

1. Avoid flows that cross over multiple entities. Use the on-page connectors for such situations. This
keeps the document relatively simple and easy to read. Another way to avoid lines crossing over
multiple entities is to list the entities in the order that they appear in the process when you label
your flowchart columns.
2. Make sure that if a document enters the system, you also show where it ends up. For example,
once a document is received by an entity, is it forwarded on to another entity? Filed away? Sent out
to an external entity? Ensuring completeness of document flows in this way makes the flowchart
easier to follow because there are no questions or ambiguities about what happens to the docu-
ments that enter or are generated in the system.
3. Where a document is copied, number each individual copy, so their individual flow through the
system can be traced.
4. Show documents moving from entity to entity in each column — that is, you should be able to see
the source and destination of the document.
5. The filing of documents does not require a manual process symbol. You can simply show the flow
of the document into the file symbol, which makes it clear that filing has taken place.
6. Processes should have an input and an output. For example, a manual process should have
an input (e.g. a source document) and an output (perhaps a new document and the original
document).
7. Only document normal processing operations of the system. Where an error routine or abnormal
processing takes place, this can be indicated with an annotation and shown separately on a dif-
ferent flowchart.
8. Where necessary, use annotations to explain or clarify any ambiguities in the flowchart.
9. Manual data stores can only be accessed by people and can only have paper documents entering
and exiting them.
10. Electronic data stores can only be accessed by the computer. For each inflow or outflow from an
electronic data store, there needs to be a related computer process, for example, retrieving data or
capturing data.
11. The columns in the flowchart should correspond to the internal entities shown in your physical
DFD.
12. Ensure that symbol labels add meaning. For example, don’t just label the paper document symbol
with the Word document. This is obvious from the symbol. The label should say what document it
is. A similar rule applies to labelling computer processes and manual processes.
13. Manual processes can only be performed by people.
14. Computer processes can only be performed by computers.

FIGURE 7.22 Rules and pointers for flowchart preparation and presentation

Also, as you draw flowcharts, keep in mind the conventions discussed in looking at how to read a
flowchart. The important things to recall are: (1) the organisational divisions are across the top of the
flowchart, (2) the flowchart symbols are used to depict what happens in the system, and (3) the flowchart
should generally flow from left to right and top to bottom.
Once you have attempted the flowchart, compare it with figure 7.23. You may have some slight
differences in how you have labelled processes and ordered the columns, but your attempt should be
comparable.

CHAPTER 7 Systems mapping and documentation 315

 Warehouse clerk Computer Dispatch administrator Accounts receivable

a (5)
Sales office
Initialled picking slip
Sales order

Sales order

(1)
Compares
goods to (6)
Sales order
paper work
(8)
Prepares
packing slip
Updates sales
(7)
(2) order status Sales order no.

Packing slip
Extract courier
(9) Couriers
list
(12)

Picks and (9)

packs (3)
goods Chooses
courier
Approved
couriers
(10)
Initials
packing slip Updates sales
(11)
order Courier approval
b
(4)

Initialled packing slip (13) Sales order Initialled picking slip

Sales order Shipping Sales order

notice Shipping notice 2

Reviews
(5) (14)
sales order
(16)

a Creates shipping Customer PO

(15)
notice waiting
Matches (23)
Sales order delivery
acceptance
(24)

Creates bill of Initialled picking slip

Shipping notice 1
lading Initialled picking slip Sales order
Shipping notice 2
(17) Sales order Shipping notice 2
Bill of lading
Customer purch ord
(18)

Bill of lading (25)

Checks &
Matches
attaches Sales orders
to be
invoiced
(19) (21)

Shipping notice 1
Initialled picking slip
Bill of lading
Sales order
Shipping notice 2

(20)

(22)
b
Shipping area

FIGURE 7.23 Completed systems flowchart

316 PART 2 Systems characteristics and considerations

7.8 Comparing the different documentation
techniques
LEARNING OBJECTIVE 7.8 Compare and contrast different forms of systems documentation.
Having gone through the process of reading and preparing process maps, DFDs and systems flowcharts,
it is useful to revise some of the key concepts covered by thinking about the relationships, similarities
and differences among the different types of documentation.
The process map details how a process is performed within an organisation, what entities are
involved in the process and what each entity does within the process. The process map gives an
overall view of the organisation’s process design and allows the interactions among entities across
the organisation to be seen. This process perspective can also be obtained from the systems flow-
chart, which shows the entities and the tasks performed by the different entities in a process. How-
ever, there is a slight difference in the information about the process that can be obtained from these
two diagrams. One example of this difference is that the process map does not show what is actually
involved in performing the activities that make up a process. For example, a process rectangle on
the process map may be labelled ‘Check goods for shipment’ but we do not know how this check is
actually carried out. In comparison, the flowchart shows the activity being performed and what the
entity performing the task uses to complete this activity. This is where the extra detail of the systems
flowchart can be useful. It can show whether it is a paper document, electronic data transfer or some
other form that is part of this activity, how the information is stored (e.g. in paper or electronic form)
and whether the process is manually or electronically performed. So the process map, in conjunction
with the systems flowchart, shows what is being done and who does it, as well as what is being used
as part of the process. The two in combination provide a very comprehensive picture of a business
process.
In contrast, the DFDs have less detail. Recall that the context diagram tells us nothing about what
happens within the system of interest. Rather, it merely shows the external entities that interact with
the system. The context diagram can be expanded into physical and logical DFDs. The physical DFD
shows who the entities are that are involved in a process and the flows among the entities, but gives
no details about what the entities are actually doing. Compare this with the process map and systems
flowchart, which not only identify the entities but also give an insight into what activities they are
performing. Conversely, the logical DFD shows what processes are performed within a system but
not who performs the processes. That is similar to having a process map without labelling the swim
lanes. This is because preparing a logical DFD requires grouping the entities. After the grouping
process, there can be several activities grouped together involving different entities and this cannot
be represented in a logical diagram. That is, the process map presents an ungrouped view of the pro-
cess; activities that are logically grouped together in preparing the logical DFD are individually sep-
arated out in the process map, thus allowing detail of the activities and the entities performing these
activities to be shown.
From this discussion, you can start to see the relative strengths and weaknesses of each form
of documentation. The information each type provides depends on the questions asked about a
system’s operation, so it becomes necessary to prepare the full set of documentation. The discussion
so far should not be seen as an indication of one form of documentation’s superiority over another.
For example, when designing a system, a logical DFD may be useful for understanding the process
stages that occur and the data that they need. The specifics required for a flowchart can be cap-
tured later in the development effort. Alternatively, to understand the interaction between entities,
again for systems design and improvement purposes, a physical DFD may be sufficient. Accordingly,
all forms of documentation are equally important, with the appropriate form of documentation for
a particular situation dependent on the demands of the situation or the questions that need to be
resolved.

CHAPTER 7 Systems mapping and documentation 317

 Failure to prepare a full set of documentation leads to a loss of valuable detail about a sys-
tem’s operations. Imagine trying to redesign a system with just a context diagram and physical
DFD; it would be practically impossible with no idea of what the activities are within the system.
Hopefully, you can start to appreciate the complementary nature of the different forms of systems
documentation and their importance to an organisation for system design, re-engineering, auditing
and monitoring.

SUMMARY
7.1 Justify why systems documentation is important to the organisation and the
accounting function.
Systems documentation plays an essential role in the organisation, serving as the organisational
memory of how the systems are designed and operate. Systems documentation is the business’s
roadmap for how systems operate and plays a critical role in the process of systems development.
In addition, for the accountant, systems documentation is a means of understanding the audit trail
within the organisation as well as the design of business processes and the way data moves through
these processes.

7.2 Communicate how systems documentation can be used as a part of business process
redesign and re-engineering.
Systems documentation can have a number of uses in the organisation, including helping in the planning
and execution of systems development and redesign, and preserving the organisational memory of how
systems were designed and how they operate.

7.3 Reflect on how the accountant and auditor can be exposed to systems documentation.
The accountant will be exposed to systems documentation in a range of ways, including through systems
development, auditing and internal control based work. As the accountant possesses knowledge of the
necessary accounting processes and controls, they will often play an important role in reviewing existing
systems and in the design of new systems. This will often involve working with systems documen-
tation. Audit work, both internal and external, places an emphasis on understanding how a process is
designed and operated and assessing aspects such as control design and operation. This will require an
understanding of how a system operates, which can be acquired by referring to systems documentation.
Additionally, flowcharts and other documentation can be used by the auditor as a way of recording their
understanding of how a system operates.

7.4 Appraise how legislative reform has impacted systems documentation.

In Australia, with the mandatory and legally binding status given to the auditing standards, financial
statement auditors are now required to adhere to the prescribed standards. These standards include
requirements that the auditor understand how an organisation and its processes operate and indicate a
range of documentation techniques that can help in this regard. In addition, the Sarbanes–Oxley legis-
lation in the United States places requirements on management and auditors regarding their control
systems. This legislation extends to include the preparation and maintenance of systems documentation
by Australian companies trading on US stock exchanges.

7.5 Recognise and interpret different forms of systems documentation.

The different forms of systems documentation provide a different perspective on a system. The pro-
cess narrative provides a text-based description of the operation of a system. The context diagram
provides an overview of the external entities that interact with the system of interest. This can be
expanded to depict the internal entities that make up the system of interest (physical DFD) and
the processes within the system of interest (logical DFD). The process map shows the entities and

318 PART 2 Systems characteristics and considerations

provides a summary of the major stages/activities that operate within a system. The flowchart goes
into more detail, showing the entities and the activities and also providing an insight into how the
activities are performed (e.g. manual or automated). In each diagram, the emphasis is on mapping
the movement of data through the system, whether it be between internal entities or between stages
within the process.

7.6 Explain the concept of a balanced set of systems documentation.

A balanced set of systems documentation requires that the external entities and the data flows to the
external entities are consistent across the context diagram, physical DFD and logical DFD. The diagrams
are looking at the same system, albeit each from a different perspective, so there is no reason why the
external entities should differ between the diagrams.

7.7 Generate different forms of systems documentation.

The steps provided in the discussion in the chapter outline how to prepare the various forms of systems
documentation.

7.8 Compare and contrast different forms of systems documentation.

The different forms of systems documentation provide alternative perspectives on the system of interest.
No format of documentation is necessarily superior to the other; rather, the document technique that
is to be used will depend on the problem or question being asked. Each type of documentation tells a
slightly different story on the operations of the process, and the three documentation approaches (pro-
cess maps, DFDs and systems flowcharts) complement each other. There is no one perfect approach; all
three approaches should be used.

KEY TERMS
Balanced data flow diagrams Diagrams (context diagram, physical DFD and logical DFD) with the
same external entities and flows.
Business process The activities that work together to achieve business objectives.
Context diagram A representation of the system of interest and the entities that provide inputs to, or
receive outputs from, the system of interest.
Data flow diagrams (DFDs) Graphical representations of the data flows that occur within a system.
Decomposing or stepwise refinement The process of breaking a logical DFD down to a lower level to
extract more detail about a process within the diagram.
Entity A representation of a real-world thing or object that is involved in a process and corresponds to
a table in a relational database.
Error routine A routine that is performed when the system does not function as is normally
expected.
External entity Any entity that provides inputs into a process or receives outputs from a process.
Internal entity An entity that processes or transforms the data within the business process of interest.
Level 0 data flow diagram The highest level logical DFD providing an overarching view of the
processes that occur.
Level 1 data flow diagram The second level logical DFD that takes one of the process bubbles from
the level 0 diagram and expands it to provide detail about the activities that occur within the process.
Logical data flow diagram A diagram that illustrates the processes that take place within a system,
the flows among these processes, and how these processes interact with the external entities that
provide inputs to, or receive outputs from, the system of interest.
Physical data flow diagram A diagram that provides details of the entities involved in a process and
the flows between those entities, as well as their interaction with external entities.

CHAPTER 7 Systems mapping and documentation 319

Process map A simple graphical representation of a business process, detailing the activities that
occur, the areas of the business responsible for completing the activities, and any decisions that need
to be made as part of the process.
Process narrative A written description of how a process operates.
System of interest The system or process that is the focus of the documentation; it will have a clear
boundary or scope.
Systems flowchart A flowchart that illustrates a system and its inputs, processes and outputs in
more detail than a process map or DFD, providing information about the documents and processes
performed within the system, as well as who is involved in the system.

DISCUSSION QUESTIONS
7.1 How does systems documentation add value to an organisation? Why should
organisations invest in the preparation of systems documentation? (LO1, LO2)
7.2 How would an accountant’s use of systems documentation differ from an auditor’s
use of those same documents? (LO1, LO3)
7.3 What is the primary purpose of each of these forms of systems documentation? (LO2, LO3)
(a) Process map
(b) Context diagram
(c) Physical DFD
(d) Logical DFD
(e) Systems flowchart
7.4 Discuss the information value of lower-level logical DFDs. Why might it be necessary
to go beyond a level 0 logical DFD? (LO3)
7.5 Compare and contrast process maps and systems flowcharts. (LO2, LO5)
7.6 Who is likely to be the primary user of each of these documents (a) the logical DFD,
(b) the physical DFD and (c) the context diagram? (LO2, LO5)
7.7 Describe how error routines are depicted in DFDs. (LO7)
7.8 What are the differences between internal and external entities? (LO5)
7.9 What techniques would you use to ensure that you create a balanced set of DFDs? (LO6)
7.10 What are the two characteristics that you would look for to verify that a set of DFDs are
balanced? (LO6)
7.11 Explain what is meant by decomposing a logical DFD. (LO5)
7.12 What is the difference between a level 0 and a level 1 logical DFD? (LO5)
7.13 Why is it possible to create differing valid representations of a system when preparing a
flowchart, process map or logical DFD when there is only one valid representation
for a physical DFD and a context diagram? (LO5, LO7, LO8)
7.14 Explain how a narrative should be used when preparing a systems flowchart. (LO5, LO7)
7.15 Critically analyse how corporate legislation such as Sarbanes–Oxley has impacted
management attitudes towards systems documentation. (LO4)

SELF-TEST ACTIVITIES
7.1 Figure 7.24 is an example of: (LO5, LO8)
(a) a logical level 0 DFD.
(b) a physical DFD.
(c) a context diagram.
(d) a process map.
(e) a logical level 1 DFD.

320 PART 2 Systems characteristics and considerations

 1.1
Confirm
inventory
Sales details
Bank
(6)
(2)
n
io
at (5)
m
r ils
nfi ta
Inventory Co de
1.2
Validate
Payment details
payment

Validated sales details

Sales

(9)
(7)
1.3
Record sale

(8)

FIGURE 7.24 Diagram for self-test activity 7.1

7.2 A logical DFD shows: (LO5)

(a) the groups of entities logically involved in a business process.
(b) how an activity is performed.
(c) the logical grouping of activities in a business process.
(d) the methods for performing activities in a process.
(e) all of the above.
7.3 A systems flowchart: (LO5)
(a) must always have a data store if there are paper documents involved.
(b) must always contain on-page connectors.
(c) includes physical as well as electronic flows.
(d) requires more than one entity.
(e) must be balanced.
7.4 A balanced set of DFDs (logical, physical and context) (i) must have the same external entities,
(ii) must have the same number of bubbles in the logical and physical DFDs, (iii) cannot contain
only one external entity, (iv) must have the same number of flows to and from external entities,
(v) require that the number of flows in the system is the same in the logical and physical
DFDs.(LO6)
(a) i and iv
(b) iii and v
(c) i and ii
(d) ii and v
(e) iv and v
7.5 An external entity: (LO6, LO7)
(a) performs information-processing activities.
(b) can only provide inputs to the system.

CHAPTER 7 Systems mapping and documentation 321

 (c) can only receive outputs from the system.
(d) does not perform information-processing activities.
(e) is not part of the organisation.
7.6 Which of the following narratives best describes the flowchart illustrated in figure 7.25? (LO5)
(a) A manual process generates a document that is keyed into a computer. Data input is saved,
then a new document is printed and filed in alphabetical order.
(b) An external entity sends a document and data are input into the system. The computer
processes and stores the data, then displays the data input on a screen. The data are reviewed,
then the document is filed in numerical order.
(c) A manual process generates a document and data are keyed into the system. The data input is
processed and saved. The document is sent to another department for filing.
(d) An external entity sends a document and data are input into the system. The computer
processes and stores the data, then displays the data input on a screen. The data are reviewed,
then the document is filed in alphabetical order.
(e) An external entity sends a document and data are input into the system. The computer
processes the data, then displays the data input on a screen. The data are reviewed, then the
document is filed in alphabetical order.

FIGURE 7.25 Diagram for self-test activity 7.6

322 PART 2 Systems characteristics and considerations

PROBLEMS
7.1 You are working as a business systems consultant with an internationally respected consulting
firm. One of your clients is considering re-engineering its core business processes. During
preliminary discussions, the CIO makes the following suggestion, ‘How about we just put together
some process maps and physical DFDs for the redesign project team; it seems a much better use
of corporate resources to invest in fully documenting the new processes rather than wasting time
and money on documents we know are going to be outdated and thrown away.’ Concerned by
this approach, you decide to prepare a response in writing clarifying the value of various forms of
systems documentation within an organisation.
As part of this discussion you need to explain the relationships between process maps, DFDs and
systems flowcharts, as well as the differences among them. You also need to explain why it is useful
to prepare differing forms of documentation. You need to recommend which of the various forms of
documentation should be prepared for the redesign team to use. (LO1, LO2, LO8)
Required
Write the report that you would submit to the CIO. You should include a discussion of the
following points:
•• The purpose of preparing systems documentation and the role it plays in the organisation.
•• The relationships among the process map, systems flowchart and DFDs.
•• Why it is necessary to prepare the different documents and is not possible just to rely on one form
of documentation.
What documentation you recommend should be prepared for use by the
redesign team.
7.2 Alpha Ltd offers an audiovisual equipment hire service. The online sales process is described
below.
The customer sends an equipment hire request form containing their name, email address,
phone number, dates of booking and equipment required. The Sales Assistant checks the
details are complete and sends the form through to the Sales Consultant. The Sales Consultant
uses the computer to check whether the equipment requested will be available on the dates
required. The Sales Consultant emails the customer to advise them whether or not the
equipment is available, and how much the equipment hire will cost. If the equipment hire
is not available on their nominated dates, the customer is given some alternative hire dates.
The email advises the customer to reply within seven days if they wish to proceed with the
hire. The Online Sales Consultant files the hire request form in date order in their ‘Awaiting
confirmation’ file. (LO7)
Required
For the process described:
(a) Prepare a structured narrative table.
(b) Prepare a process map.
(c) Prepare a context diagram.
(d) Prepare a physical DFD.
(e) Prepare a logical DFD.
(f) Prepare a systems flowchart.
7.3 Figure 7.26 contains a context diagram and a logical DFD for the sales process at Beta Ltd.
However, these diagrams contain several errors. Identify the errors contained in each of the
diagrams and explain why they are errors. (LO5, LO8)

CHAPTER 7 Systems mapping and documentation 323

 Accounts Cus
tom
receivable er d
etai
ls

det s
ails
e
(19)

Sa l
(13)

Payment details Sales Despatch details

(5)
process
(18)
Bank
Shipping
(6) department
Confirmation details

Confirm
Bank ation d
etails
(6)

(5)
Despatch details
(20)
Paym 1.0
ent d (9)
etails Order entry

(2)
(8)

(7) Inventory
Financial
controller
Sales
(12)
(13)

2.0
(11) Sales etails
reporting Sales d

(16)
(17)

Reviewed sales
reports
Sal
es
Sales report det
ails

3.0
(19) Despatch
reconciliation

FIGURE 7.26 Diagrams for problem 7.3

324 PART 2 Systems characteristics and considerations

7.4 Delta Ltd sells and installs solar panels. Their main customer base is homeowners but they also
occasionally do a large industrial installation. The billing process for Delta is described below.
Once an installation date has been confirmed, the Installation Team Leader prepares and sends
a completed Confirmed Installation form to Accounts Receivable. The Billing Officer enters the
details into the computer, which saves the sales order data and prints two copies of an invoice. The
Billing Officer collects the printed invoices from the computer print room and sends them to the
Installation Team Leader. The Installation Team Leader checks the details and posts one copy of
the invoice to the customer. As all installation invoices must be paid in full before the installation
takes place, the installation request form is matched to the invoice and the matched documents are
filed in customer number order in the ‘Awaiting payment’ file. (LO2, LO7, LO8)
Required
For the process described above:
(a) Prepare a structured narrative table.
(b) Prepare a process map.
(c) Prepare a context diagram.
(d) Prepare a physical DFD.
(e) Prepare a logical DFD.
(f) Prepare a systems flowchart.
(g) Would you recommend that Delta uses the same billing process for their large industrial
installations? Why or why not?
7.5 The following is a description of ordering food at Gamma Restaurant.
The Waiter records customers’ food and drink orders by writing the details on an order form.
The order form is given to Kitchen staff for use when preparing the food and drinks. Once all
the food and drinks have been given to the Waiter for delivery to the table, the Kitchen staff
give the order form to the Cashier. The Cashier enters the order details into the computer, saves
the sales details and then two copies of the bill are printed. When the customers have finished
their meal, the Waiter collects one copy of the bill from the Cashier and gives it to the customer.
Gamma accepts only cash payments. The customer pays the Cashier and keeps their copy of
the bill as their receipt. The Cashier puts the cash in the cash drawer, writes ‘paid’ on the other
copy of the bill and files it in the sales file. (LO2, LO7, LO8)
Required
For the process described above:
(a) Prepare a structured narrative table.
(b) Prepare a process map.
(c) Prepare a context diagram.
(d) Prepare a physical DFD.
(e) Prepare a logical DFD.
(f) Prepare a systems flowchart.
(g) If you were asked to redesign this process, what would be your major
recommendation?
7.6 The following is a description of booking a taxi through Epsilon Online.
The customer uses a mobile phone app to submit their booking request including their pickup
location, their destination and the number of passengers. The Epsilon computer sends the job details
out to the GPS-enabled digital taxi terminal of every driver in their taxi network and records the job
with a status of ‘Open’. Drivers wanting to bid for the job do so by clicking a ‘bid’ symbol on the job
displayed on the screen of their digital taxi terminal. The digital taxi terminal submits the bid along
with the current GPS coordinates (i.e. the current location) of the taxi, and then saves the job details.
Two minutes after the job was originally relayed, the Epsilon computer calculates which of the bidding
drivers is closest to the pickup point, assigns the job to them and updates the job status to ‘Assigned’.
The Epsilon computer notifies the digital taxi terminal of the winning driver that their bid has been

CHAPTER 7 Systems mapping and documentation 325

 successful, and the original job details are retrieved from the digital taxi terminal and displayed for the
driver. The Epsilon computer notifies the customer that a taxi has been allocated and the details of the
taxi number plate and estimated time to arrival are sent to them. (LO7)
Required
For the process described above:
(a) Prepare the process narrative.
(b) Prepare a process map.
(c) Prepare a context diagram.
(d) Prepare a physical DFD.
(e) Prepare a logical DFD.
(f) Prepare a systems flowchart.
7.7 You are conducting an audit of a business process and your client has given you a flowchart
that they have prepared to represent their online bookings process. The client advises you that
the flowchart was recently prepared and represents how the current process operates. You have
also done your own research and written a description of your understanding of how the process
operates, based on your observations of the business in action, interviews with staff, and use of
Zeta’s online booking system.
The client-prepared flowchart and your description of the process are shown below. (LO5, LO7)

Your narrative
Zeta is an online business offering last-minute hotel bookings. Zeta has no physical retail presence; their
24/7 global business is conducted from a small inner-city office in Melbourne. Zeta has three staff, in
addition to the Manager/Owner of the business, a Customer Service Officer, a Provider Liaison Officer,
and an IT Officer. Zeta creates all their web content in-house, but uses an outsourced hosting service to
manage the delivery of content to their customers.
Customers browse and search the Zeta website, and once they have found what they want they click
on the ‘book it’ button and are taken to a secure online booking form. The customer enters their per-
sonal details (name, street address, email address and phone number). The customer also enters their
credit card details (card type, card number, card security number, expiry date and name on card) using
this same screen. Zeta requires a 20 per cent non-refundable deposit for all bookings; the remainder of
the booking must be paid for no later than 7 days before the date of travel.
Immediately after each booking is made, Zeta receives a preformatted electronic Booking Advice
from the web host company, which includes the customer’s personal details, along with their payment
details and booking details (the hotel name, and dates for check in and check out). Payment details
received are as follows: the total amount of the booking, the amount of deposit paid and the amount
deducted for service fees (the web host company takes 2 per cent of all deposits as their commission
and forwards the remaining 98 per cent of the deposit directly on to the provider hotel). At 11 pm every
day the computer automatically opens and processes the ‘Awaiting Daily Processing’ file, which con-
tains the preceding 24 hours’ Bookings Advice notifications.
The computer checks whether the customer name and email address match against any prior
booking. If the customer details don’t match (which is most often the case), a new customer record
is created. Once the customer record is available, the computer automatically creates and saves a
Booking record. After all the Booking Advice notifications have been successfully processed, the
transactions are deleted from the ‘Awaiting Daily Processing’ file. Every Sunday evening at 7 pm
the computer generates an Invoice for each Booking. The Invoice details the total amount of the
Booking, the deposit already paid and the remaining amount outstanding, along with the full details
of the accommodation booked and the payment due date. These invoices are emailed directly to
the customer. After the Invoice processing is complete, the computer calculates the payments due
to provider hotels using the total invoiced to customers less 10 per cent, which Zeta retains as their
booking commission. The computer records the amounts payable to the provider hotels, and the
commission revenue earned.

326 PART 2 Systems characteristics and considerations

 Customer

@11 pm daily
Receives booking
advice

Throughout the day

Creates customer
Awaiting daily record
processing

Customers

Open bookings &

check customer
details

Creates booking
record Bookings

Deletes processed
Deleted bookings booking records

Every sunday
@ 7 pm

Generates invoice
Invoices

Calculates provider
payments & Customer
commission
revenue

Accounts Commission
payable revenue

FIGURE 7.27 Diagram for problem 7.7

CHAPTER 7 Systems mapping and documentation 327

 Required
(a) Identify the inconsistencies between the flowchart and the written narrative.
(b) Assuming that the written narrative is correct, prepare a flowchart that correctly depicts the
operation of the process.
(c) Prepare a context diagram for the process.
(d) Prepare a physical DFD for the process.
(e) Prepare a logical DFD for the process.
7.8 In a discussion with a colleague the following statement is made to you: ‘I was explaining
data flow diagrams to our client this morning. It took a while but eventually they understood
that divisions of their organisation must be shown as internal entities, and other businesses or
customers must be shown as external entities.’ (LO5)
Required
(a) Evaluate the extent to which your colleague is correct.
(b) Justify whether your colleague is right or wrong by referring to the definition of internal and
external entities. Use examples to justify your answer.

SELF-TEST ANSWERS
7.1 e, 7.2 c, 7.3 c, 7.4 a, 7.5 d, 7.6 d

ENDNOTES
1. Booth, R 1995, ‘To be or not to be: model that process’, Management Accounting, vol. 73, no. 4, p. 20.
2. Auditing and Assurance Standards Board 2009, Auditing Standard ASA 200 Overall Objectives of the Independent Auditor
and the Conduct of an Audit in Accordance with Australian Auditing Standards, paragraph 3, www.auasb.gov.au.
3. Auditing and Assurance Standards Board 2011, Auditing Standard ASA 315 Identifying and Assessing the Risks of Material
Misstatement through Understanding the Entity and Its Environment, paragraph 18, www.auasb.gov.au.
4. Auditing and Assurance Standards Board 2011, Auditing Standard ASA 315 Identifying and Assessing the Risks of Material
Misstatement through Understanding the Entity and Its Environment, paragraph 144, www.auasb.gov.au.
5. Booth 1995, p. 20.
6. Auditing and Assurance Standards Board 2011, Auditing Standard ASA 300 Planning an Audit of a Financial Report,
www.auasb.gov.au.
7. New Zealand Institute of Chartered Accountants 2007, ISA (NZ) 315 Identifying and Assessing the Risks of Material
Misstatement through Understanding the Entity and Its Environment, www.nzica.com.
8. Bradford, M, Richtermeyer, SB & Roberts, DF 2007, ‘System diagramming techniques: an analysis of methods used in
accounting education and practice’, Journal of Information Systems, vol. 21, no. 1, pp. 173–212.
9. House of Representatives of the United States of America 2002, Sarbanes–Oxley Act of 2002.
10. Ivancevich, DC & Sawyer, RS 2004, ‘Flowcharting basics for internal auditors’, Internal Auditing, vol. 19, no. 5, pp. 26–31;
Reed, RM, Pence, DK & Doviyanski, A 2006, ‘Mending the holes in SOX: the control matrix as an internal audit tool’,
Internal Auditing, vol. 21, no. 1, pp. 18–22; Bradford, Richtermeyer & Roberts 2007.
11. PricewaterhouseCoopers 2005, Sustainable from the start, www.pwc.com.
12. PricewaterhouseCoopers 2005.
13. Jones, RA & Lancaster, KAS 2001, ‘Process mapping and scripting in the accounting information systems (AIS) curriculum’,
Accounting Education, vol. 10, no. 3, pp. 263–78.
14. Bradford, Richtermeyer & Roberts 2007.
15. Table constructed from results in Bradford, Richtermeyer & Roberts 2007, p. 184.
16. Based on Auditing and Assurance Standards Board 2009; Stimpson, J 2007, ‘Audit tools adapt to changes’, The Practical
Accountant, vol. 40, no. 8, pp. 40–42; Reed, Pence & Doviyanski 2006; Stimpson, J 2006, ‘Technology’s impact on auditing’,
The Practical Accountant, vol. 39, no. 12, pp. 38–40; Ivancevich & Sawyer 2004; House of Representatives of
the United States of America 2002.
17. Fulscher, J & Powell, SG 1999, ‘Anatomy of a process mapping workshop’, Business Process Management Journal, vol. 5,
no. 3, pp. 208–237; Jones & Lancaster 2001; Bradford, Richtermeyer & Roberts 2007.
18. Jones & Lancaster 2001, p. 266.
19. Burns, M 2007, ‘A better way to flowchart’, CA Magazine, June/July, p. 16.

328 PART 2 Systems characteristics and considerations

20. Damelio, R 1996, The basics of process mapping, Productivity Press, New York, cited in Jones & Lancaster 2001, p. 267.
21. Smith, KT & Smith, LM 2003, ‘Tools and techniques for documenting accounting systems’, Internal Auditing, vol. 18, no. 5
(Sept/Oct), pp. 38–45.
22. Smith & Smith 2003.
23. Jones, RA, Tsay, JJ & Griggs, K 2005–06, ‘An empirical investigation of the task specific relative strengths of selected
accounting and information systems diagramming techniques’, The Journal of Computer Information Systems, vol. 46, no. 2,
pp. 99–114; 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, vol. 7, pp. 170–204.
24. Smith & Smith 2003.
25. Hunt, VD 1996, Process mapping: how to re-engineer your business process, John Wiley & Sons, Inc., New York, pp. 174–77.
26. McCarthy, WE 1982, ‘The REA Accounting Model: a generalized framework for accounting systems in a shared data
environment’, The Accounting Review, July, pp. 554–77.
27. Burns 2007, p. 16.
28. Lehman, MW 2000, ‘Flowcharting made simple’, Journal of Accountancy, vol. 190, no. 4, pp. 77–88.
29. Smith & Smith 2003.

ACKNOWLEDGEMENTS
Photo: © Zadorozhnyi Viktor / Shutterstock.com.

CHAPTER 7 Systems mapping and documentation 329

CHAPTER 8

Internal controls I
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

8.1 describe the evolution of corporate governance
8.2 explain the principles of corporate governance
8.3 explain the importance of information technology (IT) governance
8.4 summarise the principles of COBIT 5
8.5 explain the significance of internal controls
8.6 describe the components of the COSO internal control framework
8.7 explain how financial reporting risks are linked to financial statement assertions
8.8 evaluate how the COSO and COBIT frameworks are complementary and compatible.
Introduction
Have you ever set yourself a goal that you desperately wanted to achieve? Aimed at achieving a certain
grade in an end-of-semester exam? Wanted to save enough money for a new smart phone or a car? If you
have, then you have been through the process of setting yourself an objective. No doubt, as you strove
towards attaining that objective, you kept a check on how you were going. If your goal was to save a
certain amount of money, you probably would have checked your bank account regularly. If you wanted
a distinction grade on your end-of-year exam, you presumably would have attended classes and kept up
to date with class material. For every goal you want to achieve, there are actions that need to be put in
place to attain it.
It is the same story for any business. A business sets goals and then goes about trying to achieve
them. Setting goals and trying to achieve them are the role of a sound corporate governance structure.
The corporate governance structure includes the internal control system. There is a range of alternatives
for how corporate governance and internal control structures are designed. This chapter presents some
of the concepts about the structure and operation of such systems. These structures and systems allow
a business to check whether it is achieving its goals and objectives, part of which includes making sure
that the right things are being done within the organisation.
This chapter also introduces you to the role of internal controls and how they fit within the overall
management and governance of the organisation. The chapter will take you through the concepts of
corporate governance and IT governance, introduce you to some well-known IT governance stan-
dards and explain how these standards fit within a framework of sound corporate governance. The
topic of internal controls is introduced through a discussion of the COSO and ERM frameworks. As
part of this coverage, a definition of internal controls will be elaborated upon, with its components
explored in detail, providing you with the basis for looking at the application of specific controls in
the next chapter.

CHAPTER 8 Internal controls I 331

8.1 Evolution of corporate governance
LEARNING OBJECTIVE 8.1 Describe the evolution of corporate governance.
Everything that happens in an organisation with regard to goal setting, risk management, performance
measurement and management relates to the concept of corporate governance (sometimes referred to
as enterprise governance). Put simply, corporate governance relates to how organisations are managed.
In turn, the management of organisations is central to the topic of internal controls, as will become
evident when we look later in the chapter at the example of the corporate governance principles of the
Australian Securities Exchange.

What is corporate governance?

Corporate governance, as the name implies, refers to the way that organisations are managed and gov-
erned. More formally, it is defined by the Organisation for Economic Co-operation and Development
(OECD) as:
the set of relationships between a company’s management, its board, its shareholders and other stake-
holders  .  .  .  [it] provides the structure through which the objectives of the company are set, and the
means of attaining those objectives and monitoring performance are determined.1
The OECD Corporate Governance Committee launched a further review of the OECD principles of
corporate governance in 2014. This review was partially in response to the global financial crisis, which
revealed severe shortcomings in corporate governance.
The Australian Securities Exchange (ASX) Corporate Governance Council released the Corporate
governance principles and recommendations (third edition) on 27 March 2014. Corporate governance is
described as:
the framework of rules, relationships, systems and processes within and by which authority is exercised
and controlled within corporations. It encompasses the mechanisms by which companies, and those in
control, are held to account.2
The dominant approach to corporate governance has been the shareholder-centred approach because
of its emphasis on shareholder value. However, corporate governance should include the interests of all
stakeholders, including individuals, organisations and society, because globalisation has changed the
nature of the organisation.3
The Australian Securities Exchange Corporate governance principles and recommendations (third
edition) explains that organisations should inform the market of their governance arrangements so that:
• security holders and other stakeholders in the investment community can have a meaningful dialogue
with the board and management on governance matters;
• security holders can factor that information into their decision on how to vote on particular resol-
utions; and
• investors can factor that information into their decision on whether or not to invest in the entity’s securities.4
Under the ASX Corporate Governance Principles, entities listed on the Australian Securities Exchange
are required to have a majority of independent directors on an ‘if not, why not’ basis.
Corporate governance is about the many relationships in which an organisation is involved and how
these relationships are managed. Note that the relationships that impact on an organisation’s manage-
ment are both within and external to the organisation. For example, the OECD definition refers to the
organisation’s relationship with external stakeholders that, if we were to use the example of a mining
company, could include those in surrounding areas who may be impacted by potential noise, waste or
pollution levels. Corporate governance is about how such relationships are managed by the organisation.
The reality for an organisation is that, if these relationships are not managed properly, the chances of busi-
ness success are significantly reduced. For example, potential stakeholders that fall under the broad scope of

332 PART 2 Systems characteristics and considerations

the corporate governance definition include suppliers/creditors, customers/debtors, shareholders, debt pro-
viders and employees. This complex web of stakeholders that the organisation interacts within requires the
organisation to have a means of managing the interactions with stakeholders to facilitate the attainment of
business objectives. This is what corporate governance is all about — putting in place policies and struc-
tures that allow for the various relationships of the organisation to be successfully managed, in order that the
organisation can work towards the attainment of its goals and objectives. This will include issues relating to
the management of relationships with external parties, as well as those relating to the internal operations of
the organisation, including executive remuneration, risk management and levels of disclosure.
While the definition presented above may suggest that corporate governance is relevant only at the level
of the individual organisation, in fact this could not be further from the truth. While it is important that indi-
vidual organisations have appropriate corporate governance mechanisms in place (these will be discussed
later in this chapter), it also needs to be recognised that the impacts of these mechanisms extend to the wider
economy. This is evident from examining the OECD’s documentation on corporate governance, which refers
to the importance of corporate governance in the wider economy, including areas such as investor confidence,
the ability to attract investment funds and the overall functioning of financial markets. The Financial System
Inquiry report (November 2014) noted that 80 000 customers had suffered from financial detriment totalling
more than $5 billion, or $4 billion after compensation and liquidator recoveries, due to the failure of organ-
isations such as Storm Financial, Opes Prime, Westpoint, agribusiness schemes and unlisted debentures.5
The question you may be asking, though, is how does the concept of corporate governance relate to
accounting and accounting information systems? As mentioned above, corporate governance mechan-
isms relate to how an organisation achieves its goals and monitors and rewards organisational perfor-
mance. At an overall level, a key part of the planning and monitoring of organisational performance will
rely on accounting, with the accounting statements prepared by an organisation being one of the major
ways it communicates details of its performance to relevant stakeholders — predominantly investors —
allowing them to evaluate performance and make investment decisions. In this sense, accounting reports
are a key mechanism of corporate governance and the attainment of accountability.
Looking deeper than this, the idea of a business achieving its goals and objectives was mentioned
in the corporate governance definition, with the corporate governance structure providing the means
through which objectives are set and monitored. These objectives will come from the organisation’s
board, which is vested with the responsibilities associated with the successful management of the com-
pany. These objectives will flow through to the lower levels of the organisation where they will be
implemented. This means that the operation of the business processes will be impacted by the goals and
objectives that the organisation adopts. For example, if the board decides to pursue a cost-based strategy,
differentiating itself from competitors by its low-cost and efficient production methods, it will impact
on the way the production business process is designed, as well as the data that is gathered across the
process in order to measure performance. From this example, we can see how the decisions and policies
that are made as part of a corporate governance structure will impact on lower operational levels of the
organisation. The monitoring of how these high-level decisions and policies are enacted is where internal
control systems play a role. This will be discussed further later in this chapter.

Brief history of corporate governance

The late 1980s in Australia will be remembered for a series of corporate failures. One prominent example
in Victoria was the collapse of Pyramid Building Society. At around the same time, in the late 1980s and
early 1990s, the United Kingdom experienced a period of heightened attention on the topic of corporate
governance. This attention came about as a result of a number of cases of seemingly unexpected com-
pany failures and cases of fraud, as well as concerns about governance matters such as the role of the
auditor and the ever-common issue of executive remuneration.6
These events served to heighten the focus on corporate accountability and governance in the
United Kingdom and culminated in the release of the Report of the committee on the financial aspects
of corporate governance7 (also known as The Cadbury report, after the committee chairman Adrian

CHAPTER 8 Internal controls I 333

Cadbury). The committee was chartered to investigate financial reporting, accountability and issues of
corporate governance, and produced a series of recommendations. This and similar subsequent reports
have aimed primarily at financial reporting and auditing controls, including those that relate to the main-
tenance of proper accounting records and ensure the reliability of information within the information
system.8 However, the impact of the recommendations had consequences for accounting information
systems because the information system is central to the preparation of financial reports.
In the early 2000s, the United States witnessed some stunning corporate collapses: Enron, the resources
giant, floundered amid allegations of fraudulent financial reporting and an ill-informed board of directors.9
There were also issues of concern with the structure of the board of directors and senior management and
their relationship with the external auditor, with the latter being clouded by issues revolving around a lack of
independence.10 Australia has also witnessed its own share of dramatic corporate failures. Once a national
icon founded upon the traditions of a proud family, the blue and gold insignia of Ansett Airlines was removed
permanently from our skies because of insolvency. Add to this retail giant Harris Scarfe, which collapsed
following debts of $160 million in 2001 and was subsequently reopened by new owners after being restruc-
tured,11 insurance company HIH and phone company One.Tel, and you have a longer-than-wanted list of
failures in the corporate environment. In more recent times, the global financial crisis brought about some
sizeable corporate concerns for several organisations once considered insurmountable, with General Motors
being just one example. The issue that has emerged from this crisis is how organisations deal with finan-
cial risk, with attention on organisational risk management and decision-making processes, as well as the
potential need for wider regulatory framework reform.12 Organisational risk management refers to the way
an organisation identifies and manages the various risks that it faces in its operations. Risks can come from a
range of sources, including financial activities, the internal environment and the influence of external factors
such as regulation. The concept of risk management will be discussed further later in this chapter.
Company failures of any sort are undesirable, often leading to unemployment and financial hard-
ship for those affiliated with the formerly solvent organisation, the loss of capital by investors, or large
social impacts for the community in which the organisation operated. As a result, the reactions to large
corporate collapses have been strong and traditionally focused on why the collapse occurred, including
finger-pointing at the way that the organisation was managed and how the various risks and threats were
addressed — in other words, corporate governance.
Following the Enron collapse in the United States, and confronted with large public pressure for
increased accountability for large corporations, in July 2002 then US President George W. Bush signed
the Sarbanes–Oxley Act into existence. The act aimed to tighten corporate governance procedures within
a company, representing ‘government’s way of putting legal teeth into the basic precepts of good cor-
porate governance and ethical business practices’.13 The legislation has implications for internal controls
because section 404 requires the company to report to its shareholders on the design and effectiveness
of its internal controls and requires that these reports be audited by an internal auditor. It also places the
overall responsibility for internal controls on the CEO, with section 302 requiring CEOs to sign that they
are responsible for the disclosure controls and procedures within a company.14
In 2003, the Australian Securities Exchange created a corporate governance document that provided
guidelines for listed companies. The document was consistent with the principles expressed in the
OECD guidelines and contained ten principles for companies to follow when setting up their corporate
governance structure. This document was subsequently revised and re-released in 2007, with the second
edition containing eight principles for corporate governance. These eight principles were updated in
June 201015 and the ASX released an amended version of the principles. In March 2014, Corporate
governance principles and recommendations (third edition) was released with eight principles slightly
updated from the 2010 version. These are the principles that are discussed in the following section.
The management of corporations came under increased scrutiny due to the global financial crisis,
which saw some companies face increased financial pressure and failure, and the global market suffer
estimated losses in excess of $5 trillion.16 The crisis highlighted that self-regulation was not necessarily
working. It also led to a need for government bailouts since many victims were ‘innocent bystanders’

334 PART 2 Systems characteristics and considerations

(e.g. employees, people with superannuation funds tied to company profits and investors concerned
about the security of bank deposits). The crisis also raised issues of regulatory oversight of the financial
system and the need for increased awareness of general governance issues.
While Australia has, to date, largely avoided the brunt of the crisis — recording continual economic
growth attributable to mining and reasonably sustained consumer confidence17 — it has not been without
its concerns. As an example, in 2008 ABC Learning was placed into receivership. ABC Learning was one
of Australia’s largest childcare chains, employing more than 16 000 staff across more than 1000 centres
and tending to the needs of more than 100 000 children.18 Its collapse led to the federal government
outlaying more than $50 million to cover staff redundancies and employee entitlements of former
ABC Learning staff. It was estimated that the company also had unsecured creditors of approximately
$1.5 billion, as well as significant amounts owing to major banks.19 The failure of ABC Learning has been
linked to ad hoc and flawed accounting processes as well as ethical and corporate governance issues.20
The Australian Securities and Investments Commission (ASIC) carried out an investigation into the col-
lapse and two people appeared before the courts in relation to allegations about the execution of their
duties as directors,21 with both of them being committed to stand trial.22 The former chief financial officer
of ABC Learning Centres Limited was charged with three counts of authorising false or misleading infor-
mation.23 As we shall see in the discussion in this chapter, a company’s board and auditors play key roles
in corporate governance and the application of corporate governance principles.

8.2 Principles of corporate governance in Australia

LEARNING OBJECTIVE 8.2 Explain the principles of corporate governance.
The Australian Securities Exchange Corporate Governance Council Corporate governance principles
and recommendations (third edition) document, released on 27 March 2014, notes that organisations
should not use a legalistic approach to corporate governance disclosures. Each organisation should
explain their corporate governance framework using a holistic approach that provides the information
stakeholders require to make investment decisions.24
The original policy document from the ASX Corporate Governance Council identified ten factors that
can lead to strong corporate governance.25 The ten principles were revised in the second edition of the
corporate governance guidelines in 2007. There are eight principles and 29 specific recommendations
for corporate governance outlined in the most recent edition of the guidelines, the Australian Securi-
ties Exchange Corporate Governance Council Corporate governance principles and recommendations
(Third Edition). The eight principles are designed to provide guidance and flexibility on how organ-
isations report corporate governance.26
1. Lay solid foundations for management and oversight. This principle looks at how the organisation
is structured, particularly focusing on the board and management. Typical areas of attention will be
how the board and management are evaluated as well as the distribution of authority between the
board members and the rest of the organisation. In particular, this section should specify the board’s
responsibility for the design and implementation of internal controls.
2. Structure the board to add value. This principle is concerned with ensuring that there is an appro-
priate number of directors, with appropriate skill and position. An area of interest in this principle
is also the mix between executive and non-executive/independent directors. Executive directors are
those directors that are also full-time employees of the company, while non-executive directors sit on
the board but are not involved in the operations of the company in any other way. The ASX defines
an independent director as ‘a director who is free of any interest, position, association or relationship
that might influence, or reasonably be perceived to influence, in a material respect his or her capacity
to bring an independent judgement to bear on issues before the board and to act in the best interests
of the entity and its security holders generally.27 The argument for the presence of non-executive
directors on a board is that non-executive directors provide an independent perspective for board

CHAPTER 8 Internal controls I 335

 decisions and corporate governance issues. This principle also requires that members of the board
have access to all the information they require in order to carry out their responsibilities.
3. Act ethically and responsibly. This section emphasises the need for the organisation to have clearly
specified codes of conduct for employees and management. The codes of conduct can relate to legal
obligations as well as standards for dealing with various organisational stakeholders. Codes of con-
duct also include the procedures to be followed when investigating potential unethical activities
within the organisation. An example could be an organisation not allowing employees to trade in the
shares of the company and the procedure for dealing with the breach.
4. Safeguard integrity in financial reporting. This principle covers the measures that an organisation
should consider as a means of ensuring that the financial reports provide a ‘truthful and factual presen-
tation of the company’s financial position’.28 Some measures that would be considered here include the
use of an audit committee to interact with the external auditor. (This is discussed later in the chapter.)
5. Make timely and balanced disclosure. This principle addresses the means by which information is
communicated to investors and the timeliness and factuality of the information that is released, so
investors can assess the impact of the information when making investment decisions.
6. Respect the rights of security holders. Companies, a specific legal form of an organisation, have a separ-
ation of ownership and control. This places owners (or shareholders) in a position where they rely on
the company’s management to provide information about the company, including financial perfor-
mance. Accordingly, shareholders should receive timely communications from the company and have
an opportunity to participate in the general meetings held by the company. A trend among companies
in this area is the increased use of websites for presentation of information and announcements — with
options for the use of other technology, including webcasts and teleconferencing, as well as archives of
press releases and financial data and transcripts of significant meetings or briefings.29

AIS FOCUS 8.1

Availability of information to shareholders

A publicly held company provides information for shareholders on its website. For example, Westpac
Banking Corporation includes on its website shareholder information, presentations, news and docu­
ments that are useful for decision making.30 The Australian Securities Exchange provides search capa­
bilities for shareholders to find company information, including share prices, annual reports, news and
other important information.31 Since 2009, the Office of Interactive Disclosure (OID) of the United States
Securities and Exchange Commission has required some public companies to submit their financial
statements in the XBRL (eXtensible Business Reporting Language) interactive data format. The reason
for using XBRL is because using this XML (Extensible Markup Language) based software automates
business information requirements on, for example, the preparation, sharing and analysis of financial
reports. XBRL32 labels companies’ financial and other information with codes, called taxonomies. These
taxonomies are updated each year by International Financial Reporting Standards (IFRS) (see www.ifrs
.org/xbrl/pages/xbrl.aspx for the latest taxonomy). The Australian Securities and Investments Com­
mission (ASIC) is the business owner of financial reporting taxonomy in Australia. ASIC updates the IFRS
taxonomy for Australian companies each year once IFRS has released a new version. ASIC makes any
necessary changes to the IFRS taxonomy to take into account Australian standards and disclosure
requirements.33 The role of IFRS is to provide transparency, accountability and efficiency in financial
markets around the world. XBRL taxonomies are developed in multiple languages to assist organ­
is­ations in achieving electronic standards.

7. Recognise and manage risk. Risks can operate in two ways: they can provide benefits (upside) or lead
to losses or negative consequences (downside). This principle requires the board to review the risks that
the organisation faces and devise appropriate risk management policies and procedures. A major part
of this risk management process is the establishment and monitoring of the internal control system34
(discussed later in this chapter).

336 PART 2 Systems characteristics and considerations

8. Remunerate fairly and responsibly. The organisation should be able to demonstrate a clear link between
company performance and executive remuneration. The area of executive compensation is commonly
a target for criticism in times of economic or company downturn, leading to questions about why a par-
ticular amount is being paid to an individual. There is a need to recruit and retain the appropriate experi-
ence; however, sound governance also requires that remuneration is commensurate with performance.
Figure 8.1 is a case study that highlights the attention some aspects of corporate governance have
received from the popular press. Read the article and try to relate the issues it raises back to the ASX’s
eight principles of corporate governance.

Two strikes and you’re possibly out!

Corporate governance has received considerable attention in recent years, as companies have come
under increased scrutiny in light of the events of the global financial crisis and concerns about levels of
unemployment and economic activity around the globe. Despite surviving the global financial crisis and
avoiding recession, Australia has been no exception to this focus on corporate governance. One par­
ticular area under scrutiny is the level of executive remuneration. Executive remuneration is not a new
area of attention, having received coverage in the past as executives received large amounts of money
even when their company was associated with poor performance or socially contentious news items.
Examples included former Telstra chief executive Sol Trujillo, who received a $2.58 million bonus even
though both profits and the company’s share price had fallen. This attracted political attention from the then
treasurer. The board of James Hardie also allocated itself a bonus even though it was dealing with compen­
sation claims for asbestos-related illnesses among former workers. It was reported that the then Federal
Treasurer, Peter Costello, saw this as symptomatic of a bad corporate culture.35 This led to suggestions from
some avenues that executive remuneration should be capped. The ACTU issued a statement claiming that
in some cases the level of remuneration received was not representative of the effort required.36
These concerns prompted the federal government to commission an Australian Productivity Com­
mission report into executive remuneration. The report was timely given the ‘considerable interest [in
executive remuneration levels] from shareholders, business groups and the wider community  .  .  .  particu­
larly as we [Australia] face almost unprecedented turmoil in global financial and equity markets.’37
It is generally recognised that Australian companies need to be in a position to attract and retain the best
management team, including, in some cases, seeking international executives. One argument has been
that, if companies want to be able to recruit the best management, then they also need to be able to offer
remuneration that is competitive in the international market.38 There is also the classic risk–return argument,
which posits that remuneration should be commensurate with the risk undertaken by the directors when
they assume their position. Other arguments for the levels of pay have been based around agency theory
and the need to align the interests of the principal (owners) and the agent (managers).39
The Productivity Commission found that there was no overall problem with remuneration levels, which
generally moved with performance and were subject to increased accountability over recent years.40 How­
ever, this was countered by incidents of some companies not following best practice when setting remuner­
ation, as well as some large termination payments and complex remuneration structures being put in place.41
The Productivity Commission made 17 recommendations, one of which was the introduction of a two-
strike rule for executive remuneration. The idea involves shareholders voting on the remuneration report that
is put forward by the company. If more than 25 per cent of shareholders reject the report in the first year, then
the company must explain, in the subsequent report, how it has dealt with the issues raised from the ‘no’
vote. If the report is rejected a second time, the shareholders can elect to pass a spill resolution which would
see the board stand for re-election at an extraordinary general meeting (see figure A for an explanation).
A motivating force behind this proposal was to add to the level of accountability that executives have
to their shareholders and to provide shareholders with an avenue for expressing support or otherwise
for remuneration levels.42
Other recommendations addressed concerns about the structure of remuneration committees within com­
panies — specifically their size and composition — as well as restrictions on the manner in which company
executives holding shares are able to vote on remuneration-related matters at the annual general meeting,
and the format and type of information that is provided to shareholders in the remuneration report.43

FIGURE 8.1 Corporate governance and executive remuneration (continued)

CHAPTER 8 Internal controls I 337

 FIGURE 8.1 (continued)

On 23 February 2011, the two-strike rule was passed by the Parliament as an amendment to the
Corporations Act 2001. It applied to companies from 1 July 2011. The changes were met with mixed
responses from the corporate world. Early results showed several companies receiving more than the
25 per cent disapproval in the first year of operation of the legislation.44

Annual general meeting

Year 1 Meeting papers
– vote on remuneration report

VOTE ON REMUNERATION REPORT

‘no’ vote < 25% ‘no’ vote ≥ 25%

No further action Engage, explain, modify

remuneration practice

Annual general meeting

Annual general meeting
Year 2 – vote on remuneration report
– resolution for director re-election

VOTE ON REMUNERATION REPORT AND RESOLUTION

‘no’ vote < 25% ‘no’ vote ≥ 25%

Resolution not activated

Resolution activated

vote ≤ 50% vote > 50%

No further action
within Extraordinary general meeting
90 Meeting papers
days – re-election of directors, subject to resolution

FIGURE A Operation of the two-strike rule

Source: Productivity Commission 2009, Executive remuneration in Australia, p. xxxii.

338 PART 2 Systems characteristics and considerations

 Some companies criticised the changes, arguing that they could lead to instability for the company and
inflationary pressure on executive remuneration.45 Another risk comes about if the board is spilled at
the second no vote. Directors may interpret this as a no-confidence motion and, as a result, leave the
organisation.46 It was also suggested that the law change could distract attention from more important
issues, such as the company’s strategic objectives.47 Other companies have recognised the need to
better link pay, shareholder returns and company performance, with two Rio Tinto executives giving up
cash bonuses in 2011.48
The debate continues about whether the ruling is in the correct form to achieve the outcome of better
corporate governance.49
In a report by PWC (February 2015) on executive remuneration trends, financial year 2014 saw a
reduced number of strikes in the ASX200. The ASX100 reports had two strikes. However, there were
some organisations in the ASX200 that narrowly missed a strike, although the issues were not directly
related to executive remuneration. The issues included governance and board composition. The report
notes that the strikes have not led to shareholders supporting a board spill in any instance since the
introduction of the two-strike rule in 2011.50
Arguably, the changes to the legislation match the ASX Corporate Governance Principles, repre­
senting a means for shareholder involvement and promoting better communication between the share­
holder and the company.
Questions to consider
1. How does the two-strike rule relate to the corporate governance principles?
2. Explain approaches that an organisation could use to reduce the criticism it may receive for its
remuneration policies.

8.3 IT governance
LEARNING OBJECTIVE 8.3 Explain the importance of information technology (IT) governance.
As is evident from the previous discussion on corporate governance, the responsibilities of those
vested with management and control in the organisation are varied. The corporate governance roles
that derive from the ASX principles include many dimensions, such as the responsibility for the man-
agement of operations and processes in the organisation, and dealing with risk and internal controls.
Governance principles also place some responsibility on organisations for how they manage and use
information technology within the organisation. The issue of information technology (IT) governance
is an important one, since IT investment is of significant value and IT is increasingly being incorpor-
ated into organisations, whether in simple ways (e.g. establishing websites and basic e-commerce
and electronic communication systems) or more advanced organisation-wide ways (e.g. implementing
enterprise resource planning systems and integrating systems with those of customers and suppliers).
Given the increasing importance of IT in organisations, the governance and management of IT has
implications for many of the areas we examine in this text. This section introduces IT governance,
including some of the IT governance frameworks and standards that are used to guide organisations
in IT governance.

What is IT governance?
IT governance is a subset of corporate governance. As for other areas of corporate governance, IT
governance is a function of the board of directors and the high-level executives within the organisation.
IT governance centres on making sure the organisation is using IT in a manner that is consistent with
the overall organisational strategy.51 IT governance has become an increasingly important area for
attention as organisations face increased scrutiny from shareholders and other stakeholders about how
they are inducing accountability within the organisation.52 Accountability refers to how decisions are

CHAPTER 8 Internal controls I 339

allocated to individuals and how decisions are made and followed up. The increasing scrutiny of IT
governance also reflects the significant impact of IT on all functions and processes of an organisation. 53
The governance issues surrounding IT relate to decisions about how IT is to be implemented and used
in an organisation, as well as the methods to be used to promote the use of IT consistent with the
organisation’s intentions.
The definition of IT governance has been problematic because definitions have changed over time.
The older definitions from the 1990s concentrated on the supply of IT and the alignment of IT with
organisational strategy. The definitions were focused on the internal activities of the IT department,
which could be understood better by IT management than by IT governance. Contemporary definitions
extend previous definitions by recognising the business perspective. That is, IT can only deliver value if
business capability is enhanced.54
ISACA, an independent, non-profit global association engages in the development, adoption and use
of globally accepted, industry-leading knowledge and practices for information systems. ISACA and
Protiviti (a global consulting firm) in their fourth annual IT Audit Benchmarking Survey, released in
2014, found that more than three out of four survey participants (78 per cent) believed that IT gover-
nance was more valued than in the past.55
The IT Governance Institute stresses that IT governance is not an isolated discipline but rather is
embedded in corporate governance. The IT Governance Institute defines governance as follows:56
Governance ensures that stakeholder needs, conditions and options are evaluated to determine balanced,
agreed-on enterprise objectives to be achieved; setting direction through prioritisation and decision
making; and monitoring performance and compliance against agreed-on direction and objectives.
The international standard, ISO/IEC 38500:2015 Information technology — Governance of IT for the
organisation, provides the guiding principles for those responsible in organisations (owners, directors,
partners, executive managers and others) for the effective, efficient and acceptable use of information
technology within their organisations. The standard is applicable to all organisations regardless of size or
the extent to which the organisation uses IT. The standard, if followed, aims to provide stakeholders with
confidence in the organisation’s IT governance principles and practices.57
Juiz and Toomey (2015) argue that the standard implies that management should take responsibility
in three key areas:58
1. agenda setting for IT integration into the overall business strategy
2. ensuring an appropriate level of investment in IT business capability
3. successful operational use of IT in routine business activity.
Bear in mind that the emphasis is on the contribution that IT makes to business capability and effec-
tiveness. Note that new terms have been coined by some writers to better reflect the focus on integration
of IT into business decisions. For example, terms including Enterprise Governance of Information Tech-
nology (EGIT),59 corporate governance of IT and organisational governance of IT are used, depending
on the context.60
The bottom line is that IT governance should provide assurance that, first, IT investments generate the
required business value and, second, that any risks associated with IT are mitigated.61

8.4 COBIT framework and principles

LEARNING OBJECTIVE 8.4 Summarise the principles of COBIT 5.
COBIT was originally an acronym for Control Objectives for Information and related Technology.
It is now used in the short form: COBIT. COBIT 5 builds on previous versions of COBIT; therefore
organisations can build on what they have already implemented under previous COBIT versions. The
evolution of COBIT over nearly 20 years is shown in figure 8.2. COBIT has evolved from a purely
audit focus to a framework that integrates IT processes and functions to build the business capability
of organisations.

340 PART 2 Systems characteristics and considerations

 Governance of Enterprise IT

IT Governance

Evolution of scope
Val IT 2.0
(2008)
Management

Control
Risk IT
(2009)
Audit

COBIT 2 COBIT 3 COBIT 4.0/4.1 COBIT 5

1996 1998 2000 2005/7 2012

FIGURE 8.2 The evolution of COBIT

Source: © 2012 ISACA. All rights reserved. Used by permission.

COBIT 5, A business framework for the governance and management of enterprise IT, aligns with
the standard ISO/IEC 38500:2015. An important distinction is that ISO/IEC 38500 takes a behavioural
stance, that is, it provides guidance for IT governance behaviour. COBIT 5 takes a process stance, that
is, it provides guidance on processes, suggesting auditable performance metrics.62
COBIT 5 provides a framework for governing and managing enterprise (across the organisation) IT.63
The COBIT 5 framework enables IT to be governed and managed in a holistic manner for the entire
enterprise (organisation). COBIT 5 includes the full end-to-end business and IT functional areas of res-
ponsibility as well as the IT-related interests of internal and external stakeholders.64
The drivers for developing COBIT 5 were as follows.
1. To provide more stakeholders with the opportunity to have a say on the benefits and risks of IT as
well as the value derived from IT.
2. To address the increasing dependency of organisational success on external business and IT, including
partners, suppliers, outsourcers, cloud and other service providers.
3. Be able to deal with the vast amount of information. How do enterprises select the relevant and cred-
ible information that will lead to effective and efficient business decisions?
4. Deal with much more pervasive IT; it is more and more an integral part of the business. More people
in the business, regardless of their position, will be involved in IT projects. IT should be integrated
into the business. IT needs to be an integral part of the business projects, organisational structures,
risk management, policies, skills and processes.
5. Provide further guidance in the area of innovation and emerging technologies; this is about creativity,
inventiveness, developing new products, making the existing products more compelling to customers
and reaching new types of customers.
6. Cover the full end-to-end business and IT functional responsibilities, and cover all aspects that lead to
effective governance and management of enterprise IT, such as organisational structures, policies and
culture, over and above processes.
7. Get better control over increasing user-initiated and user-controlled IT solutions.
8. Achieve organisational value creation through effective and innovative use of enterprise IT. Achieve
business user satisfaction with IT engagement and services. Achieve compliance with relevant laws,
regulations, contractual agreements and internal policies as well as improve relations between busi-
ness needs and IT objectives.

CHAPTER 8 Internal controls I 341

 9. Connect to, and, where relevant, align with, other major frameworks and standards in
the marketplace, such as Information Technology Infrastructure Library (ITIL®), The
Open Group Architecture Forum (TOGAF®), Project Management Body of Knowledge
(PMBOK®), PRojects IN Controlled Environments 2 (PRINCE2®), Committee of Sponsoring
Organizations of the Treadway Commission (COSO) and the International Organization for
Standardization (ISO) standards. This will help stakeholders understand how various frame-
works, good practices and standards are positioned relative to each other and how they can be
used together.
10. Integrate all major ISACA frameworks and guidance, with a primary focus on COBIT, Val IT
and Risk IT, but also considering the Business Model for Information Security (BMIS), the IT
Assurance Framework (ITAF), the publication titled Board Briefing on IT Governance, and the
Taking Governance Forward (TGF) resource, such that COBIT 5 covers the complete enter-
prise and provides a basis to integrate other frameworks, standards and practices as one single
framework.65
COBIT 5 is designed to be used by organisations of all sizes, whether commercial, not-for-profit
or in the public sector. COBIT 5 is based on five key principles, as shown in figure 8.3 and outlined
following.66

1. Meeting
stakeholder
needs

5. Separating 2. Covering the

governance from enterprise
management end-to-end

COBIT 5
Principles

4. Enabling 3. Applying a
a holistic single integrated
approach framework

FIGURE 8.3 COBIT 5 Principles

Source: COBIT® 5. © 2012 ISACA®. All rights reserved. Used by permission.67

342 PART 2 Systems characteristics and considerations

 The five principles are as follows.
Principle 1: Meeting stakeholder needs. Organisations have different goals and objectives. COBIT 5 provides
the resources to support business value creation using IT. COBIT 5 can be customised to suit each organisation’s
business, realising the benefits of IT and mitigating the risks. This is important because COBIT 5 is designed for
all organisations, so each organisation needs to articulate how IT will create value for their organisation.
Value creation is a governance value for all organisations. Realising benefit value (financial, public
service or other) involves realising benefits at an optimal resource cost while optimising risk. COBIT 5
recognises that there are multiple stakeholders. Each of the stakeholders in an organisation may have
conflicting views on what creating value means. The questions asked for each decision include: For
whom are the benefits? Who bears the risk? What resources are required?
Stakeholder needs have to be translated into actions to achieve organisational objectives. The COBIT 5
goals cascade is the mechanism for translating stakeholder needs into specific, actionable and custom-
ised organisational goals, IT-related goals and enabler goals. It is important to note that the goals cascade
is not prescriptive. It should be used only as a guide. Figure 8.4 explicitly shows how stakeholder drivers
and needs influence enterprise and IT goals as well as enablers.

Stakeholder drivers
(Environment, Technology evolution, ...)

Influences

Stakeholder needs

Benefits Risk Resource

realisation optimisation optimisation

Enterprise goals

Cascades to

IT-related goals

Cascades to

Enabler goals

FIGURE 8.4 COBIT 5 Goals Cascade Diagram

Source: COBIT® 5. © 2012 ISACA®. All rights reserved. Used by permission.

There are five enablers.

•• Principles, policies and frameworks. Principles and policies refer to the communication mechanisms
put in place to convey the governing body’s and management’s direction and instructions.
•• Processes. A process is defined as ‘a collection of practices influenced by the enterprise’s policies
and procedures that takes inputs from a number of sources (including other processes), manipulates

CHAPTER 8 Internal controls I 343

 the inputs and produces outputs (e.g., products, services)’.68 (Figure 8.5 shows the complete set of
37 governance and management processes within COBIT 5.)
•• Organisational structures. This includes the key decision-making entities in an organisation.
•• Culture, ethics and behaviour. Culture, ethics and behaviour refers to the set of individual and
collective behaviours within an enterprise.
•• Information. The information enabler deals with all information relevant for enterprises, not only
automated information. Information can be structured or unstructured, formalised or informal.69

COBIT 5 Process Reference Model

Processes for Governance of Enterprise IT
Evaluate, Direct and Monitor
EDM01 Ensure
EDM02 EDM03 EDM04 EDM05
Governance
Ensure Benefits Ensure Risk Ensure Resource Ensure Stakeholder
Framework Setting
Delivery Optimisation Optimisation Transparency
and Maintenance

Align, Plan and Organise Monitor,

Evaluate and
APO01 Manage APO03 Manage
the IT Management
APO02
Enterprise
APO04 Manage APO05 Manage APO06 Manage APO07 Manage Assess
Manage Strategy Innovation Portfolio Budget and Costs Human Resources
Framework Architecture
MEA01 Monitor,
Evaluate and Assess
Performance and
Conformance
APO08 Manage APO09 Manage APO10 Manage APO11 Manage APO12 Manage APO13 Manage
Relationships Service Agreements Suppliers Quality Risk Security

Build, Acquire and Implement

BAI03 Manage BAI05 Manage MEA02 Monitor,
BAI01 Manage BAI02 Manage BAI04 Manage BAI07 Manage
Solutions Organisational BAI06 Manage Evaluate and Assess
Programmes Requirements Availability Change Acceptance
Identification Change Changes the System of Internal
and Projects Definition and Capacity and Transitioning
and Build Enablement Control

BAI08 Manage BAI09 Manage BAI10 Manage

Knowledge Assets Configuration

Deliver, Service and Support

MEA03 Monitor,
Evaluate and Assess
DSS02 Manage DSS06 Manage Compliance With
DSS01 Manage DSS03 Manage DSS04 Manage DSS05 Manage
Service Requests Business External Requirements
Operations Problems Continuity Security Services
and Incidents Process Controls

Processes for Management of Enterprise IT

FIGURE 8.5 COBIT 5 Process Reference Model

Source: COBIT® 5. © 2012 ISACA®. All rights reserved. Used by permission.

Principle 2: Covering the enterprise end-to-end. COBIT 5 integrates IT governance of enterprise IT into
enterprise governance (corporate governance). COBIT 5 does not focus only on the ‘IT function’, but
treats information and related technologies as assets that need to be dealt with just like any other asset
by everyone in the enterprise. COBIT 5 considers all IT-related governance and management enablers
to be enterprise-wide. Business processes are considered end-to-end, i.e. inclusive of everything and
everyone — internal and external — that are relevant to governance and management of enterprise infor-
mation and related IT. In addition to the governance objective, the other main elements of the ­governance

344 PART 2 Systems characteristics and considerations

approach include enablers; scope; and roles, activities, and relationships. Governance enablers are the
organisational resources for governance, such as frameworks, principles, structures, processes and prac-
tices, through or towards which action is directed and objectives can be attained. Governance can be
applied to the entire enterprise, an entity, or a tangible or intangible asset. A last element is governance
roles, activities and relationships. It defines who is involved in governance, how they are involved, what
they do and how they interact within the scope of any governance system.
Principle 3: Applying a single, integrated framework. COBIT 5 provides an overarching framework for
governance and management of IT by integrating with other IT-related standards and good ­practices. It
aligns with other latest relevant standards and frameworks, and thus allows the enterprise to use COBIT 5
as the overarching governance and management framework integrator.
Principle 4: Enabling a holistic approach. The COBIT 5 framework defines seven categories of enablers:
principles, policies and frameworks; processes; organisational structures; culture, ethics and behaviour;
information; services, infrastructure and applications; and people, skills and competencies. The seven
categories of enablers are shown in figure 8.6.

Organisational Culture, ethics

Processes
structures and behaviour

Principles, policies and frameworks

Services
People, skills and
Information infrastructure
competencies
applications

Resources

FIGURE 8.6 COBIT 5 Enterprise enablers

Source: COBIT® 5. © 2012 ISACA®. All rights reserved. Used by permission.

Principle 5: Separating governance from management. COBIT 5 provides a clear distinction between
governance and management. COBIT 5 defines governance as follows:
Governance ensures that stakeholder needs, conditions and options are evaluated to determine balanced,
agreed-on enterprise objectives to be achieved; setting direction through prioritisation and decision
making; and monitoring performance and compliance against agreed-on direction and objectives.70
Management is defined as:
Management plans, builds, runs and monitors activities in alignment with the direction set by the gover-
nance body to achieve the enterprise objectives.71
Good decisions can only be made when a systematic approach to governance and management of IT
is taken. Stakeholder requirements need to be evaluated to ensure they are taken into account.
The five principles enable the enterprise (organisation) to build an effective governance and manage-
ment framework under the leadership of the CEO.72
The regulatory environment has tightened in recent years in response to corporate scandals such as Enron,
Barings Bank and Lehman Brothers (see www.dailyfinance.com/2014/04/18/top-10-financial-scandals/

CHAPTER 8 Internal controls I 345

for the top ten scandals over the years). As a response, new laws and regulations aimed at increasing the
reliability of financial reporting were developed. An important international regulation enacted was the
US Sarbanes–Oxley Act (SOX). Other countries implemented similar regulations such as the Directive
of the European Parliament 2006/43/CE, the Company Acts in Australia and the UK, and the Italian
Law No. 262/2005 on savings.73 The governance and management practices in COBIT 5 provide the
necessary guidance to develop a system of controls. Testing of the design and operating effectiveness of
these controls permits auditors to assess against compliance with specific regulatory requirements, such
as SOX.74
Board members and executive management need to be informed of and actively involved in decisions
relating to IT. These decisions include IT strategic direction, enabling the achievement of business goals
and objectives, ascertaining and mitigating IT-related risks, and verifying that IT resources are utilised to
enhance an organisation’s business capability.75

Australian IT governance
The Australian Standard AS 8015 was published in 2005. This standard was the first formal standard to
describe the governance of IT without resorting to descriptions of management systems and processes.76
Standard AS 8015 took a principle-based approach that focused on the business outcomes of IT rather
than technical supply. AS 8015 was submitted for fast-track adoption to the International Organization
for Standardization (ISO). ISO/IEC 38500, published in 2008, was derived from AS 8015. It was the first
international standard to provide guidelines for governance of IT.
The AS/NZS ISO/IEC 38500:2010 Corporate Governance of Information Technology77 is iden-
tical and was reproduced from ISO/IEC 38500:2008. A new standard for IT corporate governance was
released in December 2013: AS/NZS 8016:2013 Governance of IT Enabled Projects. The principles
are those defined in AS/NZS ISO/IEC 38500:2010 Corporate Governance of Information Technology,
and this Standard offers guidance on the application of the principles to IT enabled projects. It provides
guidance on the way governing bodies can own and lead the governance of IT enabled projects, while
providing support to those with delegated authority to deliver those projects.78
The top ten current technology trends, according to Gartner,79 include computing everywhere, the
internet of things, 3D printing, advanced pervasive and invisible analytics, context rich systems, smart
machines, cloud computing, software defined applications and infrastructure, web scale IT, and risk-
based security and self-protection. What is clear is that organisations have to deal with increasingly com-
plex technology environments and adjust to the trends to stay competitive.

AIS FOCUS 8.2

Governance and accounting failure in Australia

A longitudinal study of the relationship between corporate collapses, accounting failure and governance
in Australia from the early 1890s to the early 2000s (110 years) examined four rounds of heavy and
unexpected corporate collapses across a number of sectors which occurred in the early 1890s, early
1960s, late 1980s/early 1990s and the early 2000s.80 The authors found that, for each time period
studied, accountants and, particularly, external auditors were implicated in the corporate collapses, and
this caused governments to increase governance regulations, including financial and auditing reforms.
The authors found in their review that, despite the increased disclosure requirements and more trans­
parent financial reporting, senior executives were not constrained by these requirements. Executives
still engaged in inappropriate or misleading accounting practices, for which they were found out. That
is, governance regulations did not produce transformations in behaviour because there was still con­
siderable scope to manipulate results. The authors also found that, while the length and complexity of
corporate financial reports has grown enormously, especially since the late 1970s/early 1980s, there is
little evidence to suggest that the quality of financial reporting, based on the dependability of results,
has improved across time.81

346 PART 2 Systems characteristics and considerations

 New cases are emerging even with all the corporate governance regulations and frameworks in place.
Two recent examples include the Sydney Ferries CEO who was jailed for fraud in 2014,82 and two former
employees of a trucking company, K&S Corporation, who were charged with fraud of $7.1 million in 2015.83
Does this mean we need more regulations and policies to enhance good corporate governance?84 Or
does it mean that, regardless of the regulations in place, the cultures of greed and short-term thinking,
for which the sole objective is to generate wealth, will prevail and lead to managers misleading stake­
holders?85 How do organisations deal with these cultural issues?

8.5 Significance of internal control

LEARNING OBJECTIVE 8.5 Explain the significance of internal controls.
Up until this point we have discussed corporate and IT governance and their implications for organ-
isational effectiveness. We now turn to internal control, which is another essential component of an
organisation’s corporate governance structure.

What is internal control?

Internal control is about putting in place systems and procedures that help the organisation achieve its
objectives. Internal control systems can be seen as fitting in as a part of corporate governance since their
primary role is to manage the different risks that the organisation faces and work towards the attain-
ment of organisational goals. The Committee of Sponsoring Organizations of the Treadway Commission
(COSO) is a joint initiative of five private sector organisations. The five organisations are the ­American
Accounting Association, American Institute of CPAs, Financial Executives International, the Asso-
ciation of Accountants and Financial Professionals in Business and the Institute of Internal Auditors.
COSO is dedicated to providing thought leadership through the development of frameworks and guid-
ance on enterprise risk management, internal control and fraud deterrence (see www.coso.org/aboutus
for COSO’s vision, mission and history). COSO released their most current version of the framework
Internal Control — Integrated Framework in 2013.
We use the COSO definition of internal control in the following definition.86
The definition is deliberately broad and reflects the following fundamental concepts:
• Geared towards achieving objectives in one or more categories: operations, reporting and compliance
• A process of ongoing tasks and activities — a means to an end, not an end in itself
• Effected by people — this is not just about policies and procedures but about people and their actions
• Able to provide reasonable assurance (not absolute assurance) to the board and management
• Adaptable to the organisation’s structure, for the whole organisation, a subsidiary, a division or a busi-
ness process.87
The Australian Standard on Assurance Engagements ASAE 3150 Assurance Engagements on Controls
(January 2015), issued by the Auditing and Assurance Standards Board, defines internal control as:88
The process designed, implemented and maintained by those charged with governance, management
and other personnel to mitigate the risks which may prevent achievement of control objectives relating
to the entity’s system. Controls included in the scope of the assurance engagement may comprise any
aspects of one or more components of control over an area(s) of activity within a defined boundary,
such as the group, entity, facility or location.

Control objectives
The COSO framework outlines three key objectives that provide organisations with different perspec-
tives on or aspects of internal control.
• Operations Objectives. The effectiveness and efficiency of the business operations of the organisation
including operational and performance goals and safeguarding against asset loss.

CHAPTER 8 Internal controls I 347

 • Reporting Objectives. The internal and external financial and non-financial reporting obligations of
an organisation. This includes reliability, timeliness, transparency or any other requirement set out by
regulators.
• Compliance Objectives. Adherence to laws and regulations to which the organisation is subject.89
These objectives can be seen as the generic aims of all organisations. They relate to the internal con-
trol system. Because of their importance, it is useful to have an explanation of what each of these objec-
tives refers to and how it affects the organisation.
Effectiveness and efficiency of operations
The objective of effectiveness and efficiency of operations encompasses the typical objectives of an
organisation, such as profitable operations and protecting its resources from theft and misappropriation.
Controls will be established to help the business operate profitably as well as to safeguard the resources
of the organisation. The distinction between effectiveness and efficiency is an important one to be aware
of. Effectiveness is how well a system is performing relative to a pre-specified goal or objective. That
is, it focuses on whether the system is performing the function it was put in place to achieve. Efficiency,
on the other hand, is how well the system is operating based on the resources required for its operation.
An example of a measure of efficiency could be a ratio of inputs required to operate a system to the
outputs generated by the system. For example, the number of transactions processed per hour of machine
time or the data entry time per sales transaction recorded. An example of effectiveness for a system
could be the number of transactions successfully processed.
As an example of a measure of effectiveness, for a transaction cycle like the sales cycle to be effective
it needs to meet its predefined purpose — typically that of processing sales transactions. This effective-
ness could be measured by a ratio of transactions processed successfully to total number of transactions.
This ratio is an indicator of how effective the system is at handling transactions. If we were concerned
about efficiency of the sales system, we might look at a measure of inputs to outputs, for example, how
many minutes are used per transaction.
Reliability of financial reporting
Throughout its life, an organisation will prepare financial reports. Under the Corporations Act 2001
(Cwlth), an Australian public company that is a disclosing entity must prepare and lodge half-yearly and
annual reports with the Australian Securities Exchange, while reporting entities must prepare general
purpose financial reports annually. The reports that are required to be lodged are specified in the Cor­
porations Act — the statement of comprehensive income (income statement), statement of financial pos-
ition (balance sheet), statement of cash flows, statement of changes in equity and the accompanying notes
to the financial statements — should be reliable and accurate, based on the qualitative characteristics of
accounting information referred to in the AASB’s Framework.90 A sound internal control system will
assist in meeting the goal of preparing reliable financial reports. This is an area that has faced increased
attention in the environment of corporate failures; for example, a common question being asked is: how
is it that a firm reported profits yet was insolvent? Or how is it that the problems in the financial report
(e.g. including false sales to bolster revenue, including incorrect classifications of items), were left unde-
tected? As we shall see when we look in more detail at internal controls in chapter 8, the structure and
design of the internal control system can contribute to the attainment of reliable and accurate financial
information. One thing to keep in mind in relation to reliable financial reporting is that, while this is one
area of focus and one area of potential risks for an organisation, organisational risks extend beyond the
financial to, for example, management of quality and processes within the organisation. The reliability
of financial reports and the risk of material misstatements will be of primary concern for auditors of
an organisation (discussed further below), but there are other aspects that the controls address that are
beyond the pure financial emphasis of the auditor.
Compliance with applicable laws and regulations
Organisations will also be faced with legislative requirements that must be satisfied. Consider the example
of a manufacturing company that may be allowed to discharge only a certain amount of pollution into

348 PART 2 Systems characteristics and considerations

the air each year. To comply with the legal limits of pollution, the organisation needs a system to mon-
itor its current discharge levels. This is an example of a type of internal control system. Alternatively,
the manufacturing company may pump used water back into a local stream. Legal requirements may
exist for the required quality and chemical content levels of the water. To help make sure the organ-
isation complies with such legal requirements, it can establish an internal control system to monitor
water quality. More generally, as mentioned above, Australian companies will be subject to the reporting
requirements specified in the Corporations Act, including how often reports need to be prepared, what
reports must be prepared and the content of the reports. Interpretation of this legislation incorporates the
accounting standards set by the Australian Accounting Standards Board, which outline the format and
content of the financial statements.91 Financial reporting by companies is scrutinised by the Australian
Securities and Investments Commission, which is vested with the power of policing the Corporations
Act and can investigate financial reporting practices by companies. As such, companies will seek to
ensure that measures are in place within the organisation to monitor activities and reporting and give
reasonable assurance that such activities and reports comply with applicable legislation and regulations.

8.6 Components of COSO internal control

framework
LEARNING OBJECTIVE 8.6 Describe the components of the COSO internal control framework.
Components of control are defined by the control framework applied. Examples of control frameworks
include COBIT 5, discussed above for IT controls, and COSO, which is used for financial controls. For
the purpose of this discussion, we will use the COSO definitions and explanations for the internal con-
trol system.
For the three control objectives to be achieved, there are five integrated control components: the con-
trol environment, risk assessment, control activities, information and communication, and monitoring.
Each of these is now discussed in detail. The COSO framework sets out 17 principles under each of the
five control components discussed in this section. This discussion will give you the foundation to apply
control concepts in chapter 9 and appreciate their operation in the transaction cycle chapters (10–12).

Control environment
The control environment sets the tone for the organisation. The board of directors and senior manage-
ment set the expectation for internal control and the expected standards of conduct. There are five COSO
principles for the control environment.
1. The organization demonstrates a commitment to integrity and ethical values.
2.  The board of directors demonstrates independence from management and exercises oversight of the
development and performance of internal control.
3. Management establishes, with board oversight, structures, reporting lines, and appropriate author-
ities and responsibilities in the pursuit of objectives.
4. The organization demonstrates a commitment to attract, develop, and retain competent individuals in
alignment with objectives.
5. The organization holds individuals accountable for their internal control responsibilities in the pur-
suit of objectives.92
The control environment is the basis for all internal control practices within the organisation and
impacts on how well the internal control structure operates. The control environment reinforces the con-
cept that leadership comes from the top, and the example set and decisions made by those in positions
of authority within an organisation will have an impact on the behaviour of those at lower levels. Some
examples of how this influence can be seen are in senior management’s attitudes towards ethics and eth-
ical behaviour, acting with integrity, philosophy and style, and commitment to competence.93

CHAPTER 8 Internal controls I 349

 ASAE 3150 outlines the two key areas for assessing the control environment in an organisation.94
1. The first area is how management, those with the oversight of those charged with governance, has
created and maintained a culture of honesty and ethical behaviour.
2. The second area relates to the strengths in the control environment elements. Do the control environment
elements collectively provide an appropriate foundation for the other components of internal control, and
whether those other components are not undermined by deficiencies in the control environment.
  If the control environment is weak, the other components of the internal control system are probably
less reliable. For example, if management has no regard for risks or risk management, it is unlikely that
the subsequent components of the internal control system (i.e. risk assessment, control activities, infor-
mation and communication, and monitoring, addressed below) will be considered or implemented.

Risk assessment
Every organisation faces risks internally and externally to achieving its objectives. Risk is defined as the
possibility that an event will occur.95 Risk assessment is about how an organisation assesses the various
risks it faces that could inhibit the successful attainment of its objectives. How does an organisation
assess risks? From an accounting information perspective, the concern will be the risks that could lead
to a material misstatement in the financial statements and therefore impact on the attainment of reliable
financial reporting. Risks could be as particular as data entry errors at the transactional level to, at a
higher level, the impact of a major customer moving to another supplier, which could bring inventory
valuation into question. Other risks may impact on the operation of the business processes and oper-
ations and on the organisation’s broader ability to achieve its objectives. For example, the possibility of
things going wrong in a business process (e.g. errors in manufacturing) to higher level risks that may
present themselves as a result of the organisation’s strategy and structure, for example, a high reliance on
IT and links with others in the supply chain. There are four COSO principles relating to risk assessment.
1. The organization specifies objectives with sufficient clarity to enable the identification and assess-
ment of risks relating to objectives.
2. The organization identifies risks to the achievement of its objectives across the entity and analyzes
risks as a basis for determining how the risks should be managed.
3. The organization considers the potential for fraud in assessing risks to the achievement of objectives.
4. The organization identifies and assesses changes that could significantly impact the system of
internal control.96
Regardless of their source (i.e. financial reporting or reporting in other parts of the organisation), the
various risks need to be considered and evaluated by those responsible for the implementation of the
internal control system.
The ASAE 3150 risk assessment process includes whether the entity has a process for: (i) identi-
fying risks which threaten achievement of control objectives; (ii) estimating the significance of the risks;
(iii) assessing the likelihood of their occurrence; and (iv) deciding about actions to address those risks.97
As an example, consider the aviation industry and its vulnerability to fluctuations in fuel prices in
AIS Focus 8.3. The process of identifying risks and linking financial reporting risks to financial state-
ment assertions are explained later in the chapter.

AIS FOCUS 8.3

Fuel prices and financials

Changes in fuel prices will impact on airlines in several ways, for example, the increased cost of inputs
(fuel for planes) and lower profitability per flight. Fuel is obviously an essential input into the aviation
industry and as such the airlines are confronted with the challenge of managing the risk of fuel price
increases. A common technique used by many airlines is to hedge the oil price. Qantas, for example, has
a hedge system in place where it agrees to fuel prices at the start of each calendar year. With the price
agreed and fixed, Qantas is not exposed to the impact of fuel price rises in the current year. ­However,

350 PART 2 Systems characteristics and considerations

 the contract must be periodically renegotiated, meaning that the agreed prices are not permanent. For
example, when Qantas’ contracted price of $72 per barrel came up for renegotiation in 2008, fuel prices
were about $130 a barrel. This of course affected the price that Qantas could negotiate in its new hedge.
Applying the risk model we can analyse the process as follows:
• Risk — fuel price increase and impact on profitability of flights and cost of inputs.
• Significance — high: impacts on key business activity and cost of essential key inputs; fuel prices
determined externally.
• Likelihood — high: fuel market volatile and subject to fluctuations.
• Action — hedge fuel prices (as had been done to fix the price at US$72 per barrel); change fleet
structure to more efficient aircraft (Qantas planned to speed up the retirement of some of its less
efficient aircraft and reallocate planes to different routes to manage fuel consumption).
The actions implemented will be considered in light of the cost–benefit that they provide for the
organisation. For example, the cost to the airline of placing a smaller, more fuel-efficient plane on a route
(reduced capacity on the flight) would presumably be less than the benefits that are gained (lower fuel
cost per flight, higher fuel efficiency).98

AIS FOCUS 8.4

Disaster recovery options

Australia and New Zealand have faced more than their fair share of disasters in recent times, with floods
devastating Queensland and northern New South Wales and earthquakes striking in Christchurch to
reap destruction and tragedy. These tragic events have highlighted our vulnerability to the elements and
nature. For businesses and government operations alike, these events have also served as the ultimate
litmus test for the viability of their disaster recovery plans. The design and implementation of the dis­
aster recovery plan will include decisions made as part of the overall corporate governance operations.
Essentially, this process requires the identification of risks as well as strategies to deal with such risks.
In the case of a natural disaster, the risk is that business continuity is threatened.
For many involved in business, the action required following the 2011 floods in Queensland would be a
challenge like none they had ever experienced. As the water levels rose around Brisbane, many buildings
were evacuated, with businesses confronted by the task of keeping things operating without being at the
office. For some organisations the measures necessary to achieve this included flying key staff members
interstate, enabling them to operate from office premises away from the rising flood water.99 The chief exec­
utive of the Bank of Queensland, David Liddy, for example, was concerned about when he and his staff
would regain access to their office building. While they housed their business records and computers on
the higher levels of the building, access would be cut if the ground floor of their building was to flood. This
situation saw Mr Liddy on the phone from the early hours of the morning, communicating with key staff to
ensure the necessary steps in the organisation’s disaster plans could be carried out.100
Virgin Australia faced similar issues, having been forced to evacuate its office headquarters and relocate
to a nearby emergency centre. As water levels rose, key staff were also flown interstate, with the CEO John
Borghetti rationalising this decision as the best way to manage the flood and the business simultaneously,
saying, ‘We’re operating from a split location because we can’t have all management in one spot and risk
being isolated — this way we’re hedged  .  .  .  Part of the contingency planning is such that we break the com­
pany into two — there’s people who manage the business of the day and people who manage the crisis.’
Mr Borghetti also made it a priority to keep communication lines open, sending regular emails to all staff and
maintaining contact with government and rescue teams.101 This meant that, in the event of a development,
Mr Borghetti would be able to promptly communicate details. Other organisations were not so fortunate,
with their disaster recovery facilities being located near the flood plains and affected by the water levels.102
Given that in many cases the office premises were evacuated, alternative means of communication
became important. Mobile telecommunications, laptops and wireless internet access proved useful to
a lot of organisations.103 Many people still needed a regular power supply, which also placed demand
on the generators and backup power supplies. It became apparent that many of the backup generators
were not able to be used since they were located on the ground floor or basement of the building they

(continued)

CHAPTER 8 Internal controls I 351

 AIS FOCUS 8.4 (continued)

were intended to power.104 Once water breached the building’s barriers, the lower levels flooded and
the backup facilities were rendered inoperable. This meant that, even though offices and data storage
located on higher levels may have been protected from the floodwaters, the offices — and the data
stored within — were rendered inaccessible by the lack of power.
Apart from raising issues about the location of generators and power supplies, these examples also
highlight issues in the selection of remote processing locations for emergency recovery centres. Reports
on the floods indicated that several emergency backup facilities, while located away from the main
office premises, were still affected by the flooding.105
This suggests that for a disaster recovery plan and, in particular, a disaster recovery centre to be
effective, the more geographically dispersed the processing centres the better, since the probability of
disparate locations being impacted simultaneously is seemingly low. This has led to cloud computing
as an alternative for consideration when developing an organisation’s disaster recovery plan.106 Prom­
inent law firm DLA Phillips Fox had such a technical arrangement in place, with the organisation’s
major servers housed in Sydney. IT staff in the firm’s Brisbane offices were able to upload the local
data to the Sydney servers. Since staff had laptops and remote access they were able to continue
operations in a relatively uninterrupted manner.107 In addition, through the IT governance within the
firm, the decision to develop applications for iPhones and iPads that staff could use to record hours
worked and access data remotely had brought about benefits during the floods and reduced disrup­
tion that would otherwise have been experienced from staff not being in the office.108
This is a variant on the concept of cloud computing, which sees organisations subscribe to third-
party provided internet-based data storage and applications, with the level of service based on the indi­
vidual subscriber’s needs. Prominent providers of cloud computing services include Amazon, Google
and Microsoft.109 Other organisations have gone down the path of arranging their own private cloud
computing based services with a telecommunications provider. Such an arrangement sees the tele­
communications provider host the servers of the company.110 Cloud computing offers advantages for
new and emerging businesses, since it is easily scalable and can grow with the organisation. In the case
of disaster recovery, the benefits are self-evident — since the data is stored off site, the ability to con­
tinue to access data in the event of a disaster is generally still present.
The four typical advantages of cloud computing are as follows:111
1. Access to the services is based on a monthly fee without requiring capital investment. This can be
of benefit for smaller organisations and new entrants and can also help with financial planning. It
represents a reduced investment in technological infrastructure — essentially all that is required is
a computer and internet access. For smaller new entrants in a market this can reduce the barrier of
entry due to underlying technology requirements.
2. Cloud computing offers a risk-management technique, since in the event of disaster the IT services are
based in a different location and still accessible.
3. The task of keeping the applications and technology up to date is left to the cloud service provider.
4. Security and maintenance can be managed by the cloud provider.
Having these recovery structures well documented is also important. It was reported that a common
finding from the follow-ups from the floods was a deficiency in documentation and consideration of
backup and restoration procedures.112 While having backups and recovery plans in place is one thing,
being able to implement them is another. The reality of staff turnover within an organisation, as well as
different fields of operation, means that the person who performs the backup may not be the person
who performs the recovery of data. This makes it important that system specifications and restor­
ation procedures are well documented, so those with the restoration task can complete it as soon as
possible.113
A further issue for consideration raised by the impact of the flooding is the inclusion of
provisions relating to disaster recovery when entering into agreements with IT service providers.
This would be an issue that would be considered as part of the IT governance program and as
part of the selection of vendors and decisions about the sources of IT services. However, it should
be noted that such contractual provisions and the use of cloud computing do not absolve the
organisation of its responsibilities relating to disaster recovery. Details should be sought about the pro­
visions that the provider has in place in the event of a disaster and how their plans would operate.114

352 PART 2 Systems characteristics and considerations

Control activities
Control activities are performed at all levels of the organisation, at various stages of the business pro-
cess and over the technology environment. Control activities may be preventive or detective and can be
manual or automated. For example, many activities for authorisation and approval are often automated.
Segregation of duties is often built into the selection and development of control activities.115 The COSO
framework consists of three principles relating to control activities.
10. The organization selects and develops control activities that contribute to the mitigation of risks to
the achievement of objectives to acceptable levels.
11. The organization selects and develops general control activities over technology to support the
achievement of objectives.
12. The organization deploys control activities through policies that establish what is expected and pro-
cedures that put policies into action.116
Management will look at the objectives of the organisation and the risks identified as threats to
achieving those objectives, and devise ways of reducing the threat of those risks. Various strategies
can be employed to negate the risks, including top-level reviews, direct management, information pro-
cessing, performance indicators, physical controls and segregation of duties.117 These specific strategies
are discussed in more detail in the next chapter when examining some of the types of control activities.
For example, if management identified the threat of inventory being stolen (and hence recorded
amounts would be different to actual amounts on hand, and assets would not be protected), then it might
respond by suggesting physical controls such as the use of a locked storeroom and periodic reconcili-
ations of stock on hand to inventory records, as well as separation of duties.
ASAE 3150 states that the use of IT affects the way in which control activities are implemented. Con-
trols over IT systems are effective when they maintain the security, confidentiality, privacy and integrity
of the data which such systems process, generate and/or store, through both effective general IT controls
and process controls, while still providing accessibility and availability of that data so that the operations
of the entity are not impeded.118
Although we are not concerned here with why these controls would meet the specific threat, appreciate
that, at this point in time, management proposes potential solutions to the threats identified.

Information and communication

Information and communication are essential to carry out internal control responsibilities so that an
organisation can achieve its objectives. Management obtains and uses relevant, high-quality information
from internal and external sources to support the functioning of the other components of internal con-
trol.119 The COSO framework has three principles associated with information and communication.
1. The organization obtains or generates and uses relevant, quality information to support the func-
tioning of other components of internal control.
2. The organization internally communicates information, including objectives and responsibilities for
internal control, necessary to support the functioning of other components of internal control.
3. The organization communicates with external parties regarding matters affecting the functioning of
other components of internal control.120
Imagine what it would be like if you were the sales manager of a large retail firm and were asked to
provide the sales budget for the next quarter without the use of any information — no sales figures or
trends, no economic indicators, nothing. What would you use as the basis of your forecast, apart from
a bit of luck and a whole lot of guessing? Clearly, this is not the way for an organisation to operate.
Within the organisation, people need enough information to be able to perform their duties. Information
and communication are therefore centred on making sure that information is with the right people at the
right time. To achieve this, it is first necessary to identify what data are needed, then capture them and
convert them to a form that is useful for those within the organisation. The information then needs to be
accessible, so that employees can use it in carrying out their daily jobs and responsibilities.

CHAPTER 8 Internal controls I 353

 Information and communication also encompasses the design of the information system, which
includes the ‘infrastructure (physical and hardware components), software, people, procedures, and
data’.121 The information system, from an accounting perspective, needs to have in place methods to
identify and record transactions, summarise transactions for reporting purposes, measure transactions,
record transactions in the correct period and produce reports that allow for appropriate decisions to be
made by management in their role as controllers of the activities of the organisation. This also includes
the techniques used to communicate the different responsibilities of people within the organisation, for
example, job descriptions, and policy and procedure manuals.122 Notice how an important part of the
design of the information system is communication of responsibilities, which leads to the concept of
‘accountability’ — a key part of the control process. For accountability to be effective, however, there
needs to be information flowing up and down through the organisation. More importantly, that infor-
mation needs to be acted upon. Even if an information system prepares a report showing that some of
the organisation’s accounts receivable are several months overdue, that report is of little use if no-one
ever acts upon it or even reads it! Information must be available and must also be communicated to the
relevant people for appropriate action.

Monitoring
Evaluations, either ongoing or separate (or a combination of the two), are used to establish which of
the components of internal control are present and functioning. Ongoing evaluations should be built
into business processes to ensure timely feedback. Separate evaluations are undertaken periodically,
depending on the assessment of risks, effectiveness of ongoing evaluations and other management con-
siderations.123 The COSO framework has two principles for monitoring.
1. The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain
whether the components of internal control are present and functioning.
2. The organization evaluates and communicates internal control deficiencies in a timely manner to
those parties responsible for taking corrective action, including senior management and the board of
directors, as appropriate.124
Ongoing monitoring activities are often built into the normal recurring activities of an entity and
include regular management and supervisory activities. Internal auditors or personnel performing similar
functions may contribute to the monitoring of an entity’s activities. Monitoring activities may also
include using information communicated by external parties, such as customer complaints and regulator
comments, which may indicate problems or highlight areas in need of improvement.125
Monitoring of an internal control system needs to occur regularly, because over time the objec-
tives of the organisation may alter or the risks confronting the organisation may change. Monitoring
is a key activity that aims to ensure that the controls in place relate to current risks faced by the
organisation. For example, the emergence of the online environment has increased the risk of fraud
through identity theft and fake or stolen credit card details. This has meant that organisations now
need to ensure that their controls relating to authenticating customer identity are up to date to deal
with this risk. Control activities used in the past may not adequately deal with the new risks pre-
sented in today’s business environment. This emphasises the need to continually monitor the internal
control system and its performance. Failure to do so ignores that the organisation, its objectives and
its environment change over time.
Monitoring can take place in several ways within the organisation and can be performed by both
internal and external parties. Those within the organisation involved in monitoring activities may include
top management, internal auditors and employees, while the external parties may include external audi-
tors and regulatory bodies. These parties will review the control system periodically and ensure that it
still fits the organisation’s goals and objectives and satisfactorily addresses any risks that may exist. The
roles of the internal auditor, top management and the external auditor in this monitoring process are dis-
cussed briefly in the following sections.

354 PART 2 Systems characteristics and considerations

Internal auditors
The Institute of Internal Auditors Australia (IIAA) explains that internal auditors work with management
to systematically review systems and operations. Internal auditors work in all sectors (public, private
and not-for-profit) and may be an employee of the organisation or an external service provider. Reviews
(called audits) identify how well risks are managed, including whether the right processes are in place
and whether agreed procedures are being adhered to. Internal auditors work across all areas of an organ-
isation. Any system that has an impact on the effective operation of an organisation may be included in
an internal audit’s scope of work.126
ASAE 3150 defines internal auditors as those individuals who perform the activities of the internal
audit function. Internal auditors may belong to an internal audit department or equivalent function or
outsourcing entity, or be co-sourced from both internal and outsourced resources.127 For a small organ-
isation, an internal audit function may not be viable. The organisation might rely on co-sourcing or
outsourcing to provide needed skills. A larger organisation will have access to resources such as a signif-
icantly broader range of experienced in-house personnel to fulfil the internal audit function.
The COSO framework specifically defines the internal auditor function and responsibilities as:
Internal auditors provide the third line of defense in assessing and reporting on internal control and
recommending corrective actions or enhancements for management consideration and implementation;
their position and compensation are separate and distinct from the business areas they review.128

Internal auditors are required to abide by the International Standards for the Professional Practice of
Internal Auditing.129 This document sets out the mandatory requirements and interpretations that clarify
concepts and terms.

External or independent auditor

An external or independent auditor is appointed to audit (examine) the effectiveness of an organisa-
tion’s internal control over financial reporting as well as the organisation’s financial statements. Auditors
use a framework such as COSO to perform an independent audit.130 In Australia, the Corporations Act
(see http://asic.gov.au/regulatory-resources/financial-reporting-and-audit/preparers-of-financial-reports/
financial-reports/ for a summary of organisations that are included) dictates what types of companies
must have a financial statement audit performed. The audit will provide reasonable assurance that:
•• transactions that occurred have been recorded and reported
•• assets and liabilities in the financial statements exist and transactions reported actually occurred
•• assets listed are owned by the organisation and liabilities owed are reported
•• amounts on the financial statements have been calculated in accordance with accounting standards
•• the statements are correctly classified with appropriate disclosures in the notes, as required by the
accounting standards.131
As part of these duties, the external auditor will assess the adequacy of the internal control system.
Auditors will also communicate with management, providing comments and feedback on the internal
control system and notifying them of any deficiencies that were detected in the internal control system.132
In the United States, as a result of the Sarbanes–Oxley Act, auditors are required to audit declarations by
the CEO about the nature and adequacy of internal control within the organisation.

Senior management
The COSO framework emphasises that senior management is accountable for internal control and the
board of directors. Senior management is also responsible for assessing the organisation’s system of
internal control in relation to the COSO framework.
The COSO framework states that, regardless of organisational structure, definitions and assignments
of responsibility, reporting lines and communication channels must be clear. This provides account-
ability over operating units and functional areas. The framework also provides the definition of reporting
lines (e.g. direct reporting/‘solid line’ versus secondary reporting/ ‘dotted line’).

CHAPTER 8 Internal controls I 355

 Responsibilities can generally be viewed as falling within three lines of defence against failure to
achieve the entity’s objectives, with oversight by the board of directors.

• Management and other personnel on the front line provide the first line of defence in day-to-day
activities. They are responsible for maintaining effective internal control day to day; they are com-
pensated based on performance in relation to all applicable objectives.
• Business-enabling functions (also referred to as support functions) provide guidance on internal con-
trol requirements and evaluating adherence to defined standards; while they are functionally aligned
to the business, their compensation is not directly tied to performance of the area to which they
render expert.
• Internal auditors provide the third line of defense in assessing and reporting on internal control and
recommending corrective actions or enhancements for management consideration and implemen­
tation; their position and compensation are separate and distinct from the business areas they review.133

Senior management within an organisation play a critical role in the design and effectiveness of the
organisation’s control system. It all starts at the top, with the board of directors responsible for setting
the pattern that will run throughout the entire organisation. Top management have an enormous impact
on the effectiveness or otherwise of internal controls within the organisation. Senior management that
puts in place structures for control, emphasises the importance of control to its middle and lower level
management, and acts upon the results of the control system sends the message to all within the organ-
isation that ethical behaviour and adherence to the control system are important. Alternatively, top man-
agement that engages in unscrupulous activities and does not consider controls to be important will send
exactly the opposite signal to all other employees in the organisation.
Some of the ways that senior management can signal its commitment to a rigorous control system
include establishing an internal audit function and supporting its independent operation in the organ-
isation, establishing an audit committee from the board of directors and having a board structure that
consists of both internal and external directors.
A company’s board of directors can consist of both executive and non-executive directors. Executive
directors are full-time employees of the company, who will typically be involved in management of the
ordinary operations of the business. By comparison, non-executive directors are not employed by the
company on a full-time basis and will usually be external appointments to the board. The benefit of the
presence of non-executive directors is that they are usually able to offer independent and unbiased per-
spectives to the running of the board.134 From a corporate governance perspective, non-executive direc-
tors are seen as more effective for monitoring and responding to management performance.
Audit committees are established by organisations to monitor the organisation’s financial performance
and as a point of liaison between the company and the internal and external auditors.135 The audit com-
mittee will be made up of a selection of the company’s directors and act as a representative group for the
company’s shareholders, since a financial statement audit is performed for these shareholders. Important
aspects to consider when designing an effective audit committee are that it is independent and able to
discuss openly any sensitive issues that may arise, and is also able to nominate an auditor and arrive
at a suitable fee, monitor the perception of auditor independence and provide a forum for sensitive
­control-related issues to be discussed.136 As part of reinforcing the independence of the audit committee,
it is thought that most of its members should be non-executive directors.137 Increasingly, the audit com-
mittee is being viewed as a key part of an organisation’s corporate governance structure and Australian
companies are required to disclose in their annual reports whether they have an audit committee in place.
As an historical reference, certain companies were mandated by the Australian Securities Exchange to
establish an audit committee for the financial year commencing after 1 January 2003.138
The control objectives, along with the internal control system components, need to be applied across
the entire organisation — from the sales department to the accounting department and the manufac-
turing department. This gives us the three-dimensional framework for internal controls contained in
figure 8.7.

356 PART 2 Systems characteristics and considerations

 ns

e
ng
io

nc
at

r ti

ia
r

pl
pe

po

om
Re
O

Function
Operating unit
Control environment

Division
Risk assessment

Entity level
Control activities

Information and communications

Monitoring activities

FIGURE 8.7 The relationship between control objectives and control components
Source: www.coso.org/documents/990025P_Executive_Summary_final_may20_e.pdf.139

Many organisations use COSO and COBIT in tandem — COSO for their financial framework and COBIT
for their IT control framework — because the frameworks are compatible and complementary. The 2013
COSO framework emphasises information technology more explicitly than in the previous version.
The cube in figure 8.7 shows that there is a direct relationship between the objectives that the organ-
isation hopes to achieve, the components which represent what is required to meet those objectives and
the organisational structure, including legal entities and operating units.
The COSO framework for internal control has received endorsement from the United States. When the Secu-
rities and Exchange Commission (SEC) required use of an internal control framework that had been exten-
sively developed and publicly distributed, the SEC mentioned the COSO framework as one such example.140

8.7 Identifying and assessing risks

LEARNING OBJECTIVE 8.7 Explain how financial reporting risks are linked to financial statement assertions.
A useful technique to identify risks is to look at the organisation’s financial statements. Cast your eye over
the different items that appear in the reports and ask yourself this question: what could go wrong that could
affect this item? This question could be answered by considering what could go wrong in calculating and
presenting the item in the statement of financial position (e.g. What could lead to a misstatement of the

CHAPTER 8 Internal controls I 357

 inventory or accounts receivable?) or by considering the actual asset or liability (e.g. What could go wrong
with the physical inventory items? What risk is our property, plant and equipment exposed to? What threats
face our computing facilities?). You could also look at sales items on the income statement, or statement of
comprehensive income, and identify events that could lead to a drop in sales revenue (e.g. loss of market
share, increased competition, poor quality products) or be falsely reported (e.g. inaccurate data about sales
being entered, false sales being entered). For assets such as inventory, risks would include physical threats
(e.g. theft or wastage and spoilage) or fraudulent recording.

Linking risks to financial statement assertions

The process of risk assessment requires a good understanding of the business, its operations, its busi-
ness processes and the environment in which it operates. A set of financial statements represent, as the
name suggests, statements of financial facts for the organisation at balance date. In other words, they
assert that these facts were the case at balance date. As such, the financial statements contain a set of
assertions, made by the preparer, about what has happened during the reporting period and the financial
position of the organisation at the end of the reporting period. An assertion is a statement or declaration
made by someone. In the case of preparing financial statements, managers are asserting that the trans-
actions in the statement of comprehensive income (or income statement) occurred and that the statement
of financial position represents the organisation’s actual financial position. As an example, preparing
the statement of comprehensive income and including the total sales revenue figure is an assertion by
management that the sales actually occurred, and have been reported accurately, correctly classified and
allocated to the correct accounting period. The organisation will have policies and procedures in place in
order to work towards these assertions being satisfied (discussed in the next section). The risks that sales
may be false or relate to a different accounting period, or may have been inaccurately reported are the
type of financial reporting risks that internal controls aim to address. If we were to consider the risks of
what could go wrong in the financial statements that could lead to them being materially misstated, we
may come up with the list in table 8.1, depending on whether we are looking at the different transactions
or events that the organisation engages in or the presentation of the material in the financial statements.

TABLE 8.1 Financial reporting risks

TRANSACTIONS — different transactions and events are impacted by:

Assertion Explanation Risk Example of risk Control focus
Occurrence All transactions Transactions may be Sales entered that have Processes to verify that
included in the financial entered that have not not occurred. transactions have taken
statements have occurred. place before being
occurred. recorded.
Completeness All transactions and Transactions may Sales occurring but not Process to check for
events that should have have been omitted recorded. missing transactions or
been recorded have (not included in the events.
been recorded. statements).
Accuracy Data relating to Data entry errors may Entering data incorrectly Processes in place to
transactions and events misrepresent the effect of (e.g. wrong dollar check data as it enters
have been correctly the event and materially amount, wrong quantity). the accounting system.
recorded. misstate the financial
statements.
Cut-off All transactions and Transactions may have Sales from next period Processes in place to
events have been been recorded in the pushed into current provide reasonable
reported in the correct wrong period. period; current period assurance that
reporting period. expenses pushed into transactions have been
the next period. correctly included in the
current reporting period.

358 PART 2 Systems characteristics and considerations

 TRANSACTIONS — different transactions and events are impacted by:
Assertion Explanation Risk Example of risk Control focus
Classification All transactions and Misclassified items could An expense that is Processes to monitor
events have been materially distort the classified as an asset the classification of
recorded in the correct financial statements. improvement would transactions and events
accounts. overstate assets and and provide reasonable
understate expenses. assurance as to the correct
application of AASB
classification requirements.
ACCOUNT BALANCES — all account balances should demonstrate:
Existence The assets, liabilities and Inclusion of assets that An asset that does Processes in place to
owners’ equity reported do not exist in order to not exist is recorded confirm asset existence
on the statement of improve the appearance to improve the overall before including them
financial position actually of the statement of financial position of the in the accounting
exist. financial position. entity (e.g. non-existent information system.
accounts receivable).
Rights and The assets are controlled Including assets or Asset items may be Processes in place to
obligations by the business and liabilities in the statement included that the ensure that the rights
the liabilities are the of financial position organisation does not and obligations attached
obligations of the entity. even if the rights and have control over (e.g. to assets and liabilities
obligations do not attach goods on consignment) exist and relate to the
to the organisation. which would lead to organisation before they
assets being erroneously are incorporated into the
included in the financial accounting information
statements. system.
Completeness All asset, liability and Not all assets, liabilities Liabilities may be omitted Processes in place
owners’ equity items and equity items have from the statement of to identify potential
that relate to the entity been included in the financial position in order completeness issues.
and should have been financial statements. to improve the apparent
recorded actually have financial position of the
been recorded. entity.
Valuation and Assets, liabilities and Incorrect valuation and Some items may not be Processes in place to
allocation owners’ equity are allocation procedures valued correctly (e.g. provide reasonable
correctly valued. have been applied to inventory may not have assurance that the
the assets, liabilities and been valued at lower of correct valuation and
equity items. cost or net realisable allocation procedures
value — NRV). Alternatively, have been applied.
items may not have been
allocated correctly (e.g.
revaluation of amounts).

There are a number of auditing standards made under Section 336 of the Corporations Act 2001 (see
www.auasb.gov.au/Pronouncements/Australian-Auditing-Standards.aspx).
Table 8.1 takes what are known as the audit assertions141 — the statements that are represented by
management when financial statements are prepared — and explains what they mean and the risks for
each assertion not being met in the financial reporting process. You will encounter these when you study
auditing and assurance services in your later studies, but their inclusion here is to highlight to you, from
a financial reporting perspective, what the financial statements purport (i.e. the assertions), the risks of
these assertions not being met and the role of internal controls in addressing these risks.
The risks of an assertion not being satisfied should be identified by the organisation and be addressed
by control activities (discussed in the next section and in more detail in chapter 9). This is one way
of thinking about the risks within the accounting information system. For example, if we look at the
first assertion — occurrence — we can consider the risk that transactions and events could have been

CHAPTER 8 Internal controls I 359

recorded but have not actually taken place (i.e. the risk of fake transactions being recorded). This has an
obvious impact on the financial reports and their reliability and accuracy.
Of course, one thing to keep in mind is that not all of a business’s risks will relate to the financial statements.
Table 8.1 focuses on the risks from a financial reporting perspective, with the financial statements being the
major output of the accounting information system. However, risks extend beyond the financial statements
and encompass the entire organisation. Risks can result from a range of factors, including the nature of the
business and the industry it operates in (e.g. refer to the earlier example of fuel prices for Qantas).
From the assertions listed in table 8.1, we can appreciate that, as a general rule, the potential threats to
consider when analysing the items in the financial statements are:
•• the potential for an asset, liability or owners’ equity item to be recorded when it does not exist or not
recorded when it does exist (existence)
•• the potential for a revenue or an expense item to be recorded when it has not occurred or not to be
recorded when it has occurred (occurrence)
•• the potential for assets, liabilities, owners’ equity, revenues and expenses to be recorded at the wrong
amount (valuation/measurement)
•• the potential for some transactions to be only partly recorded or to be omitted (completeness).
Other risks to consider could include:
•• the risk of network disruption and how that impacts on the business’s ability to operate in an
e-commerce environment
•• the risk of key suppliers or customers shifting to other organisations
•• the risk of organisational data being damaged/destroyed
•• the risk of the organisation facing changes in the external environment that impact on its operations
(e.g. changes in legislation or the regulatory environment)
•• the risk of loss of market share due to faulty or low-quality goods being produced
•• the risk of new competitors taking market position
•• the risk of unauthorised access to IT facilities or online systems.
For example, an organisation may have in place a strategy of being a low-cost producer, allowing it to
attract a particular customer group. In order to achieve this strategy, it has established an alliance with a
particular overseas supplier who has agreed to provide inputs at a low price. If this arrangement was to be
impacted, for example, by a change in import regulations or import taxes, the organisation’s ability to pro-
duce cheaply and, consequently, achieve its strategic objectives could be jeopardised. Thus, when consid-
ering risks, it is important to think in terms of what could go wrong throughout the organisation should such
impacts eventuate. While as accountants looking at the accounting information system our emphasis will
be on the accounting aspects as evidenced by our examination of the assertions, internal controls cover the
entire organisation and relate to financial as well as non-financial risks that the organisation faces. As noted in
ASA 315 A37, ‘Business risk is broader than the risk of material misstatement of the financial report, though
it includes the latter. Business risk may arise from change or complexity. A failure to recognise the need for
change may also give rise to business risk. Business risk may arise, for example, from:

• The development of new products or services that may fail;

• A market which, even if successfully developed, is inadequate to support a product or service; or
• Flaws in a product or service that may result in liabilities and reputational risk.’142

Two points to take from the auditing position on risk are, first, that the auditing standards focus on risk
from a financial perspective (i.e. the risks that could lead to material misstatement) and, second, that the con-
cept of risk is broader than this, and can include risks that come from, for example, poor quality control, com-
pliance with regulatory requirements, or inefficient or ineffective operations. An example of a risk that does
not impact the financial statements could be the impact of increased environmental awareness resulting in
pressure from environmental lobby groups. While the risks that such groups may present will not necessarily
impact on the financial statements, other impacts (e.g. increased threats to the business’s position in society
or the rise of increased regulation and loss of political control) will be considered as part of risk assessment.

360 PART 2 Systems characteristics and considerations

8.8 Evaluating COSO and COBIT
frameworks
LEARNING OBJECTIVE 8.8 Evaluate how the COSO and COBIT frameworks are complementary and
compatible.
COSO and COBIT have had major revisions recently. Both the Committee of Sponsoring Organizations
of the Treadway Commission (COSO) and ISACA worked together on both frameworks to ensure that
they were complementary and compatible. A white paper was released in 2014 to explain the align-
ment and differences of COSO and COBIT.143 As discussed in earlier sections, the COSO framework
sets out 17 principles, while COBIT 5 focuses on organisational goals through the use of a goals cas-
cade model. Table 8.2 shows the relationship between the COSO principles and COBIT 5 process guid-
ance.144 The table shows that the integration of IT into corporate governance is an underlying concept
of both frameworks.

TABLE 8.2 Relationship between the COSO principles and COBIT 5

Control environment

COSO principle and description Relationship to COBIT 5

1 The organisation demonstrates a COBIT 5 processes, EDM01 Ensure Governance Framework

commitment to integrity and ethical Setting and Maintenance and APO01 Manage the IT Management
values. Framework, include activities to embed enterprise integrity and
ethical value aspects within the governance and management
framework. COBIT 5 process APO07 Manage Human Resources
includes activities to address integrity and ethical value aspects
from a human resources perspective.

2 The board of directors All five COBIT governance processes (EDM01 through EDM05)
demonstrates independence reinforce this separation.
from management and exercises
oversight of the development and
performance of internal control.

3 Management establishes, with COBIT 5 process APO01 Manage the IT Management Framework
board oversight, structures, includes activities to address the required definition of an
reporting lines, and appropriate organisational structure for the enterprise. APO01 takes direction
authorities and responsibilities in from process EDM01 Ensure Governance Framework Setting, and
the pursuit of objectives. Maintenance regarding enterprise governance requirements.

4 Management establishes, with COBIT 5 process APO01 Manage the IT Management

board oversight, structures, Framework includes activities to establish roles and
reporting lines, and appropriate responsibilities to support achievement of enterprise objectives.
authorities and responsibilities in COBIT 5 process APO07 Manage Human Resources includes
the pursuit of objectives. activities to address the attraction, development and retention of
competent people

5 The organisation holds individuals The COBIT 5 Enabler: Processes and supporting charts for all
accountable for their internal 37 processes are particularly relevant to the context of individual
control responsibilities in the pursuit accountability. The enabler and charts strongly advocate the
of objectives. assignment of responsibilities and accountabilities and provide
examples of roles and responsibilities for key individual and
group roles for all key IT governance-related processes and
activities.

(continued)

CHAPTER 8 Internal controls I 361

TABLE 8.2 (continued)

Risk assessment
COSO principle and description Relationship to COBIT 5
6 The organisation specifies The guidance for all 37 COBIT 5 processes includes process goals
objectives with sufficient clarity (objectives).
to enable the identification and
assessment of risks relating to
objectives.
7 The organisation identifies risks to The COBIT 5 Enabler: Processes guidance specifically addresses
the achievement of its objectives risk governance (process EDM03 Ensure Risk Optimisation) and
across the entity and analyses risks management (process APO12 Manage Risk). These processes
as a basis for determining how the include the practices and activities that are required to govern and
risks should be managed. manage risk effectively, including their identification, analysis and
management.
8 The organisation considers the COBIT 5 processes EDM01, APO01 and APO07 support culture,
potential for fraud in assessing risks ethics and behaviour objectives, including an enterprise’s approach
to the achievement of objectives. to fraud. COBIT 5 process MEA03 Monitor, Evaluate and Assess
Compliance with External Requirements should also be considered,
because fraud prevention (bribery, privacy, etc.) is often part of an
enterprise’s external compliance requirements.
9 The organisation identifies and The COBIT 5 Enabler: Processes guidance specifically addresses
assesses changes that could changes in the COBIT 5 process, BAI06 Manage Changes, which
significantly impact the system of is directly linked to the IT-related goal, ‘Manage IT-related business
internal control. risk’. This process, like the COSO principle, recognises that
changes within an enterprise can introduce risk and therefore need
to be a focus from this perspective. Further, as changes occur in
all areas of control activity (information, applications and general
control activities over technology), these changes are addressed by
different COBIT 5 processes. COBIT 5 process APO01 Manage the
IT Management Framework addresses the management framework
and manages changes to general controls. COBIT 5 process BAI06
Manage Changes, and for programs and projects COBIT 5 process
BAI02 Manage Requirements Definition, manage the changes to
business processes, applications and infrastructure. All changes
need to be tested and approved by following the COBIT 5 process,
BAI07 Manage Change Acceptance and Transitioning. Impacts to
business processes are handled according to COBIT 5 process
BAI05 Manage Organisational Change Enablement.
Control activities
10 The organisation selects and The COBIT 5 Enabler: Processes guidance for the 37 COBIT 5
develops control activities that processes supports enterprises in their selection and development
contribute to the mitigation of risks of control activities and other arrangements (e.g. structural
to the achievement of objectives to segregation of duties), particularly with the practices and activities to
acceptable levels. consider for IT-related enterprise processes.
11 The organisation selects and Control activities can be process activities within all of the
develops general control activities 37 COBIT 5 processes. In particular, COBIT 5 process DSS06
over technology to support the Manage Business Process Controls ensures that control activities
achievement of objectives. embedded in business processes (automated controls or application
controls) are adequately managed.
12 The organisation deploys control COBIT 5 process APO01 Manage the IT Management Framework
activities through policies that includes activities that address the implementation of enterprise
establish what is expected and policies.
procedures that put policies into
action.

362 PART 2 Systems characteristics and considerations

Information and communication
COSO principle and description Relationship to COBIT 5
13 The organisation obtains or The guidance for the 37 COBIT 5 processes includes inputs and
generates and uses relevant, outputs that are the communication of information across, and to
quality information to support the and from, the enterprise. In particular, COBIT 5 process MEA01
functioning of internal control. Monitor, Evaluate and Assess Performance and Conformance
addresses performance and conformance data, and COBIT 5
process MEA02 Monitor, Evaluate and Assess the System of Internal
Control addresses control effectiveness reviews.

14 The organisation internally Processes enabler goals (objectives) are provided for all 37 COBIT 5
communicates information, processes. The need to communicate information with stakeholders
including objectives and as part of enterprise process design and execution, to support the
responsibilities for internal achievement of process and related business goals, is addressed
control, necessary to support the in the RACI charts with the responsibilities of ‘consult’ and ‘inform’,
functioning of internal control. and the input and output suggestions that support process
guidance for the 37 COBIT 5 processes. This communication is
implemented and managed following COBIT 5 process APO01
Manage the IT Management Framework.

15 The organisation communicates COBIT 5 process EDM05 Ensure Stakeholder Transparency ensures
with external parties regarding that the communication to stakeholders is effective and timely and
matters affecting the functioning of that a reliable, consistent basis for reporting is established.
internal control.

Monitoring activities

16 The organisation selects, develops, The COBIT 5 Enabler: Processes guidance specifically addresses
and performs ongoing and/or monitoring, evaluation and assessment of internal control adequacy
separate evaluations to ascertain (COBIT 5 process MEA02 Monitor, Evaluate and Assess the System of
whether the components of internal Internal Control). This process includes the practices and activities that
control are present and functioning. are required to monitor internal controls, review business process controls
effectiveness, perform control self-assessments, identify and report
control deficiencies, ensure that assurance providers are independent and
qualified, and plan, scope and execute assurance activities.

17 The organisation evaluates and COBIT 5 process MEA02 Monitor, Evaluate and Assess the System
communicates internal control of Internal Control includes the practices and activities that are
deficiencies in a timely manner to required to identify control deficiencies, analyse and identify their
those parties responsible for taking underlying root cause, escalate control deficiencies, and report
corrective action, including senior to stakeholders as appropriate. In addition, COBIT 5 process
management and the board of EDM05 Ensure Stakeholder Transparency includes practices and
directors, as appropriate. activities to evaluate, direct and monitor stakeholder reporting and
communication requirements, including those related to control
deficiencies, to senior management and the board, as appropriate.

AIS FOCUS 8.5

Corporate governance, financial reporting  .  .  .  what else?

The corporate governance and internal control frameworks discussed in this chapter relate predomi­
nantly to regulatory requirements imposed on organisations. For example, the Corporations Act man­
dates reporting requirements for companies and the Australian Securities Exchange publishes corporate
governance policies, to which listed companies adhere. Following these requirements is a matter of
conformance — making sure organisations meet regulatory requirements to which they are subject.
Compliance with financial reporting requirements, for example, is monitored through regular financial
statement audits and the supervisory role of ASIC.

(continued)

CHAPTER 8 Internal controls I 363

 AIS FOCUS 8.5 (continued)

However, mere compliance is not sufficient for organisations, with the notion of corporate social
responsibility (CSR) gaining prominence. CSR is a broader perspective than that of simply following
legislative requirements, and includes the concept of ‘business practices based on ethical values, with
respect for people, communities, and the environment’.145 This broader emphasis brings into play the
relationships the organisation has with its many stakeholders — customers, suppliers, employees and
the community in which it operates.
Recognising the broad range of stakeholders an organisation interacts with means that a wider range
of potential risks needs to be considered. The obligations of the organisation are not limited just to
shareholders through financial reporting. Under CSR principles, the obligations are extended. While
the CSR perspective looks at economic performance, it also addresses how the organisation benefits
employees, the community in which it operates and broader society.
A particular area where CSR has gained prominence is in the interaction between organisations and
the environment, with the voice of environmental lobby groups and the increased political awareness
of environmental issues leading to consideration of the sustainability of operations into the mid to long
term, rather than just an emphasis on the current period’s profit. Mining companies are just one example
of organisations that have faced such pressures through increasing focus on their impact on the com­
munities in which they operate, especially in instances where they operate in developing countries that
may not have the resources or structures in place to effectively monitor the organisation. With this trend
has come scrutiny from corporate watchdogs that have the potential to generate negative publicity for
organisations who do not act in what is deemed to be a socially responsible manner.146
As a result, organisations are increasingly putting in place policies to deal with this broader array of
risks. An example is Rio Tinto, which on its website has extensive disclosures on how it acts to res­
pect the human rights of those in the communities where it operates, as well as the identification of its
various stakeholders and the strategies in place for managing those relationships.147 This makes the
concept of risk far wider than the consideration of financial consequences, shifting the focus beyond
financial statements when assessing organisational operations.

SUMMARY
8.1 Describe the evolution of corporate governance.
Corporate governance is the way a company is managed to create value, enforce accountability, and con-
trol and manage risks. Corporate governance principles influence the design and operation of the organ-
isation. An internal control system will be established as part of corporate governance responsibilities.
Corporate governance has long been a concern worldwide. In recent years, as we have witnessed
some major corporate collapses, attention has increasingly been placed on how organisations are being
managed. The OECD has released guidelines on corporate governance, arguing for its importance to
the capitalist markets. In Australia, corporate governance has been addressed by the ASX through the
release of the ASX corporate governance guidelines.
8.2 Explain the principles of corporate governance.
There are eight principles and 29 specific recommendations for corporate governance outlined in the
most recent edition of the Australian Securities Exchange Corporate Governance Council Corporate
Governance Principles and Recommendations (Third Edition). The eight principles are designed to pro-
vide guidance and flexibility on how organisations report corporate governance. The eight principles are:
lay solid foundations for management and oversight; structure the board to add value; act ethically and
responsibly; safeguard integrity in financial reporting; make timely and balanced disclosure; respect the
rights of security holders; recognise and manage risk; and remunerate fairly and responsibly.
8.3 Explain the importance of information technology (IT) governance.
The issue of information technology (IT) governance is an important one, since IT investment will
typically be of significant value and, as we saw in chapter 2, IT is increasingly being incorporated

364 PART 2 Systems characteristics and considerations

into organisations, whether in simple ways (e.g. establishing websites and basic e-commerce and elec-
tronic communication systems) or more advanced organisation-wide ways (e.g. implementing enterprise
resource planning systems and integrating systems with those of customers and suppliers). IT gover-
nance is concerned with the way the organisation uses IT. It takes a lifecycle perspective on IT, con-
sidering the issues from initial ideas about a system through to its implementation and operation, and
aims to ensure that IT resources are aligned with organisational goals and used effectively within the
organisation. IT governance is a process of accountability for the way that IT is adopted and applied in
the organisation. It aims to ensure a consistency between the organisation’s aims and objectives and the
way in which IT is applied within the organisation.
8.4 Summarise the principles of COBIT 5.
COBIT 5 consists of five core principles: meeting stakeholder needs, covering the enterprise end to end,
applying a single integrated framework, enabling a holistic approach, and separating governance from
management.
8.5 Explain the significance of internal controls.
Internal control is an essential part of an organisation’s corporate governance structure and helps the
organisation to meet its objectives. Internal control is about putting in place systems and procedures that
help the organisation achieve its objectives. Internal control systems can be seen as fitting in as a part of
corporate governance since their primary role is to manage the different risks that the organisation faces
and work towards the attainment of organisational goals.
8.6 Describe the components of the COSO internal control framework.
The five control components are: the control environment, risk assessment, control activities, infor-
mation and communication, and monitoring.
8.7 Explain how financial reporting risks are linked to financial statement assertions.
Financial reporting risks are those risks that present themselves as part of the financial reporting process
and that could lead to the financial statements being materially misstated. A financial statement asser-
tion is a declaration about what the financial statements represent. Potentially, financial reporting risks
can lead to assertions not being valid. Internal controls are put in place to reduce the risk of financial
reporting errors and provide reasonable assurance that the assertions are met.
8.8 Evaluate how the COSO and COBIT frameworks are complementary and compatible.
Many organisations use COSO and COBIT in tandem — COSO for their financial framework and COBIT
for their IT control framework — because the frameworks are compatible and complementary. The 2013
COSO framework emphasises information technology more explicitly than in the previous version.

KEY TERMS
Control activities The actions established through policies and procedures that help ensure
management’s directives to mitigate risks to the achievement of objectives are carried out.148
Control environment Comprises the integrity and ethical values of the organisation, including
management operating style, delegation of authority systems and the processes for managing people.
Corporate governance The way companies are managed to create value, enforce accountability and
control, and manage risks.
Internal control A process effected by an entity’s board of directors, management and other personnel
designed to provide reasonable assurance regarding the achievement of objectives relating to
operations, reporting and compliance.
Monitoring Ongoing monitoring activities designed to detect internal control deficiencies so that
action can be taken to ensure continuous improvement of the system.
Risk assessment Involves a dynamic and iterative process for identifying and assessing the risks to the
achievement of organisational objectives.

CHAPTER 8 Internal controls I 365

DISCUSSION QUESTIONS
8.1 What is the relationship between corporate governance and IT governance? (LO1, LO2, LO3)
8.2 Why is IT governance so important? (LO3)
8.3 Explain how COSO and COBIT work together to help organisations achieve their objectives. (LO8)
8.4 Explain who the stakeholders are in corporate governance and IT governance and why.
 (LO1, LO3, LO4)
8.5 Explain how COSO and COBIT 5 are complementary and compatible.(LO8)
8.6 Summarise the drivers for developing COBIT 5. (LO4, LO5)
8.7 Why does COBIT 5 clearly distinguish the terms governance and management? (LO3, LO4, LO8)
8.8 What are some current technology trends and why is it important for
an organisation to understand trends? (LO2, LO3, LO4)
8.9 Describe the importance of managing financial risks, including the possible
consequences to the organisation.(LO7)

SELF-TEST ACTIVITIES
8.1 Corporate governance is:(LO2)
(a) an internal control tool.
(b) a factor influencing internal control.
(c) a substitute for internal control.
(d) part of the control environment.
8.2 An internal control system includes the control environment component. This is best
described as:(LO5)
(a) the overall attitude of awareness and actions of management to internal control.
(b) the environment in which the business operates that it wishes to control to negate any business risks.
(c) management’s response to the risks that an organisation faces.
(d) the provision of sufficient information to enable employees to effectively operate in their roles.
(e) the monitoring of performance to ensure that the organisation’s control system is still relevant
and up to date.
8.3 IT governance is concerned with:(LO3)
(a) ensuring that the correct IT investment is always made.
(b) controlling the use of IT within the organisation.
(c) mandating selection procedures for new IT investments.
(d) policies and procedures helping to align the use of IT and strategy.
8.4 In which component of the internal control system would you see a concern with
hiring and recruitment policies? (LO5, LO6)
(a) Control environment
(b) Risk assessment
(c) Control activities
(d) Information and communication
(e) Monitoring
8.5 In which component of the internal control system would you see a concern with
reviewing the existing control system operation? (LO5, LO6)
(a) Control environment
(b) Risk assessment
(c) Control activities
(d) Information and communication
(e) Monitoring

366 PART 2 Systems characteristics and considerations

8.6 Which financial statement assertion is threatened when the organisation has recorded sales
that didn’t take place?(LO7)
(a) Occurrence
(b) Completeness
(c) Accuracy
(d) Classification
8.7 The assertion of cut-off would be at risk when:(LO7)
(a) the accounting information system accepts a value that is incorrect (e.g. 122 instead of 22).
(b) the accounting information system accepts a fictitious sale.
(c) the accounting information system includes a sale for the next financial year in this year’s
revenue figure.
(d) a revenue item is classified as an expense when entering the transaction.
8.8 Which of the following statements regarding risks for a business is false?(LO7)
(a) Risks can come from both internal and external factors.
(b) Risks faced by an organisation will always have consequences for the financial statements.
(c) Management needs to be aware of and evaluate the risks that the organisation faces.
(d) The risks identified will have varying probabilities of eventuating.

PROBLEMS
8.1 Watch the following Youtube video on ‘The ABC of a Corporate Collapse’, www.youtube.com/
watch?v=YYF6JW9vJKo&list=PL12C0ADD577F6B741. Answer the following questions:(LO5)
(a) What factors led to the failure of ABC Learning?
(b) Could the failure have been avoided? If so, how?
8.2 Read the article from The Economist, ‘Accounting scandals: The dozy watchdogs’,
www.economist.com/news/briefing/21635978-some-13-years-after-enron-auditors-still-cant-stop-
managers-cooking-books-time-some.(LO6)
(a) Explain the key issue the article raises about the effectiveness of audits.
(b) What does the article suggest as a solution?
(c) Could the COSO framework be a solution? Why or why not?
8.3 Explain the relationship between corporate governance and IT governance. (LO2, LO3)
8.4 Summarise the evolution of COBIT from the early years to the current COBIT 5.(LO4)
8.5 Explain the purpose of COBIT 5.(LO4)
8.6 Explain the relationship between COBIT 5 and COSO.(LO8)
8.7 For each of the following companies, find the latest annual report on the company’s website
and summarise the corporate governance policy for risk assessment and integrity in financial
reporting:(LO7)
(a) Qantas (www.qantas.com.au)
(b) Woolworths (www.woolworthslimited.com.au).
8.8 For each of the following companies, find the latest annual report on the company’s website and
summarise the IT governance policy.(LO3)
(a) Qantas (www.qantas.com.au)
(b) Woolworths (www.woolworthslimited.com.au).
8.9 Select a publicly listed company and describe the extent to which it uses web technology to
communicate with shareholders and other stakeholders. Specifically, describe the extent to which it
has the following:(LO3)
(a) Financial reports (past and present results)
(b) Media releases (How far back do they go?)
(c) Webcasts of presentations or investor updates.

CHAPTER 8 Internal controls I 367

FURTHER READING
ASX Corporate Governance Council 2014, Corporate governance principles and recommendations,
3rd edn, Australian Securities Exchange Limited, Sydney, www.asx.com.au/documents/asx-
compliance/cgc-principles-and-recommendations-3rd-edn.pdf).
Auditing and Assurance Standards Board 2013, Auditing Standard ASA 500 Audit evidence,
www.auasb.gov.au/admin/file/content102/c3/Nov13_Compiled_Auditing_Standard_ASA_500.pdf.
Auditing and Assurance Standards Board 2013, Auditing Standard ASA 315 Identifying and assessing
the risks of material misstatement through understanding the entity and its environment, www.auasb
.gov.au/admin/file/content102/c3/Nov13_Compiled_Auditing_Standard_ASA_315.pdf.
Carnegie, GD & O’Connell, BT 2014, ‘A longitudinal study of the interplay of corporate collapse,
accounting failure and governance change in Australia: Early 1890s to early 2000s’, Critical
Perspectives on Accounting, vol. 25, no. 6, pp. 446–68.
COSO 2013, Internal Control — Integrated Framework, May, www.coso.org/documents/990025P_
Executive_Summary_final_may20_e.pdf.
Relating the COSO Internal Control — Integrated Framework and COBIT 2014, An ISACA COBIT
Series White Paper, www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/
Relating-the-COSO-Internal-Control-Integrated-Framework-and-COBIT.aspx.

SELF-TEST ANSWERS
8.1 b, 8.2 a, 8.3 d, 8.4 a, 8.5 e, 8.6 a, 8.7 c, 8.8 b

ENDNOTES
1. Organisation for Economic Co-operation and Development 2004, OECD principles of corporate governance, Paris, p. 11.
2. ASX Corporate Governance Council 2014, Corporate governance principles and recommendations, Third Edition, www.
asx.com.au/documents/asx-compliance/cgc-principles-and-recommendations-3rd-edn.pdf), Australian Securities Exchange
Limited, Sydney, p. 3.
3. Schneider, A & Scherer, A 2015, ‘Corporate governance in a risk society’, Journal of Business Ethics, vol. 126, no. 2,
pp. 309–23.
4. ASX Corporate Governance Council 2014, p. 3.
5. Murray, D 2014, Financial System Inquiry final report, November 2014, p. 199, http://fsi.gov.au/publications/final-report/.
6. The Committee on the Financial Aspects of Corporate Governance and Gee and Co. Ltd 1992, 2.1–2.2, www.ecgi.org.
7. The Committee on the Financial Aspects of Corporate Governance and Gee and Co. Ltd 1992.
8. Financial Reporting Council 2005, Internal control — revised guidance for directors on the combined code, October, p. 3,
www.frc.org.uk.
9. Beavers, JT 2003, ‘Are boards control-literate?’, Internal Auditor, vol. 60, no. 5, p. 84.
10. Kirkpatrick, G 2009, ‘The corporate governance lessons from the financial crisis’, Financial Market Trends, vol. 2009, no. 1,
pp. 1–30.
11. Gluyas, R 2006, ‘Accountants criticised’, The Australian, 20 October.
12. Paletta, D 2009, ‘Timothy Geithner calls for tougher standards on risk’, The Australian, 27 March,
www.theaustralian.news.com.au.
13. Deloitte & Touche LLP 2003a, Moving forward — a guide to improving corporate governance through effective internal
control: a response to Sarbanes–Oxley, January, Deloitte & Touche USA, p. 6.
14. Deloitte & Touche LLP 2003a, p. 3.
15. ASX 2011, ‘Corporate governance’, www.asx.com.au.
16. Perth Now 2009, ‘Two thirds of banks losses yet to be declared: IMF’, 22 April, www.perthnow.com.au.
17. Uren, D 2011, ‘Miners and households drive recovery as GDP growth exceeds Treasury forecasts’, The Australian,
8 December, www.theaustralian.com.au.
18. AAP 2008, ‘ABC Learning in receivership’, 6 November, www.news.ninemsn.com.au.
19. Kruger, C 2009, ‘Mission Australia to buy ABC Centres’, Brisbane Times, 9 December,
www.brisbanetimes.com.au.

368 PART 2 Systems characteristics and considerations

20. CPA Australia 2010, ABC Learning case study, www.cpaaustralia.com.au; Walsh, L 2010, ‘Groves set to explain ABC
collapse to court’, The Courier-Mail, 15 February, www.news.com.au; Walsh, L 2009, ‘Lawyers piece together puzzle of
Groves’ chosen creditors’, The Courier-Mail, 13 December, www.news.com.au.
21. Elks, S & Bita, N 2011, ‘Eddy Groves in court over ABC Learning collapse’, The Australian, 28 January, www.theaustralian.
com.au.
22. AAP 2011, ‘Groves to stand trial next May’, The Australian, 19 August, www.theaustralian.com.au; AAP 2011, ‘ABC
Learning’s Groves to face trial in May’, Australian Financial Review, 19 August, http://afr.com; Butler, B & Hawthorne, M
2011, ‘ABC directors face criminal charges’, The Age, 28 January, www.theage.com.au; ASIC 2011, ‘11–16AD — Former
ABC directors charged’, www.asic.gov.au.
23. ASIC 2013, ‘13-104MR Former ABC Learning CFO charged’, media release, 10 May 2013, http://asic.gov.au/about-asic/
media-centre/find-a-media-release/2013-releases/13-104mr-former-abc-learning-cfo-charged/.
24. ASX Corporate Governance Council 2014, p. 6.
25. ASX Corporate Governance Council 2003, Principles of good corporate governance and best practice recommendations,
March, Australian Stock Exchange Limited, Sydney, pp. 11–61.
26. ASX Corporate Governance Council 2007, Corporate governance principles and recommendations with 2010 Amendments,
2nd edition, Australian Securities Exchange Limited, Sydney; ASX Corporate Governance Council 2007, pp. 13–37.
27. ASX Corporate Governance Council 2014, p. 37.
28. ASX Corporate Governance Council 2007, p. 26.
29. ASX Corporate Governance Council 2007, p. 32.
30. Westpac, Investor centre, www.westpac.com.au/about-westpac/investor-centre/.
31. ASX, Company information, www.asx.com.au/prices/company-information.htm.
32. See www.iasplus.com/en/projects/research/short-term/xbrl for a detailed explanation of xbrl.
33. ASIC, ‘Financial reporting taxonomy development’, http://asic.gov.au/regulatory-resources/financial-reporting-and-audit/
preparers-of-financial-reports/standard-business-reporting/financial-reporting-taxonomy-development/.
34. ASX Corporate Governance Council 2007, pp. 33–4.
35. Dickins, J 2006, ‘Executive excess: how calls to stop ever-increasing corporate salaries are falling on deaf ears’, The Sunday
Telegraph, 1 October, pp. 44–5.
36. Davis, M 2009, ‘Cap salaries of chief executives: unions’, The Sydney Morning Herald, 1 June, www.smh.com.au.
37. Productivity Commission 2009, Executive remuneration in Australia, Report No. 49, Final Inquiry Report, Melbourne, p. iv.
38. Productivity Commission 2009, pp. iv, xix.
39. Productivity Commission 2009, p. xviii.
40. Productivity Commission 2009, pp. xxiii–xxiv.
41. Productivity Commission 2009, pp. xxiv–xxv.
42. Productivity Commission 2009; House of Representatives 2011, ‘Corporations Amendment (Improving Accountability on
Director and Executive Remuneration) Bill 2001 — explanatory memorandum’.
43. Productivity Commission 2009, pp. xxxvii–xli.
44. Frost, J 2011, ‘Sevior backs executive two-strikes pay rule’, The Australian, 29 October, www.theaustralian.com.au; Swan,
P 2011, ‘Big boards invite two strikes’, The Australian Financial Review, 27 October, www.afr.com.
45. McDuling, J 2011, ‘Two-strikes rule ridiculous’, The Australian Financial Review, 25 November, www.afr.com.
46. Durkin, P, Liondis, G & Wiggins, J 2011, ‘First strikes looking likely for fat cats’, The Australian Financial Review,
7 November, www.afr.com.
47. Semple, C, Bruce, E & Friedlander, D 2012, ‘Inside the minds of company directors’, The Australian Financial Review,
23 February; The Australian Financial Review 2011, ‘Executive pay row is a distraction’, 29 October, www.afr.com.
48. White, A 2012, ‘Boards weigh executive bonus clawback clauses’, The Australian Financial Review, 13 February, www.afr.com.
49. Australian Institute of Company Directors 2014, Centre for Governance Excellence and Innovation roundtable
discussion: Comments on the ‘two-strikes’ rule, video, October, www.companydirectors.com
.au/Director-Resource-Centre/Centre-for-Governance-Excellence-and-Innovation/Practice-of-governance/
Leading-director-concerned-about-use-of-the-two-strikes-rule-as-a-proxy-for-other-concerns.
50. PwC 2015, 10 minutes on … Executive remuneration trends – serenity now, February, www.pwc.com.au/consulting/assets/
publications/Ten-Minutes-Feb15.pdf.
51. Lainhart, JW 2000, ‘Why IT governance is a top management issue’, The Journal of Corporate Accounting & Finance,
vol. 11, no. 5, pp. 33–40.
52. Brown, AE & Grant, GG 2005, ‘Framing the frameworks: a review of IT governance research’, Communications of the
Association for Information Systems, vol. 15, pp. 696–712.
53. Gosling, R 2006, ‘Corporate governance: the ties that bind — how IT knits together corporate necessities’, New Zealand
Management, May, p. 70; Musson, D & Jordan, E 2005, ‘The broken link: corporate governance and information
technology’, Australian Accounting Review, vol. 15, no. 3, pp. 11–19; Lainhart 2000.
54. Juiz, C & Toomey, M 2015, ‘To govern IT, or not to govern IT?, Communications of the ACM, vol. 58, no. 2, January, pp. 58–64.
55. ISACA and Protiviti 2014, A global look at IT audit best practices, www.isaca.org/Knowledge-Center/Research/
ResearchDeliverables/Pages/a-global-look-at-it-audit-best-practices.aspx.

CHAPTER 8 Internal controls I 369

56. IT Governance Institute 2015, www.itgi.org/About-Governance-of-Enterprise-IT.html.
57. ISO 2015, ‘ISO/IEC 38500:2015 Information technology — governance of IT for the organization’, www.iso.org/iso/home/
store/catalogue_ics/catalogue_detail_ics.htm?csnumber=62816.
58. Juiz & Toomey, M 2015, p. 58.
59. Zororo, T 2014, ‘IT governance assurance and consulting: a compelling need for today’s IT auditors’, EDPACS: The EDP
Audit, Control, and Security Newsletter, vol. 49, no. 6, pp. 1–9.
60. Zororo 2014.
61. Juiz & Toomey 2015, pp. 58–64.
62. Juiz & Toomey 2015, p. 58.
63. ISACA 2012, COBIT 5: A business framework for the governance and management of enterprise IT, Introduction, www.
isaca.org/cobit/Documents/COBIT-5-Introduction.pdf.
64. ISACA 2012, COBIT 5: A business framework for the governance and management of enterprise IT, www.isaca.org/COBIT/
Pages/COBIT-5-Framework-product-page.aspx.
65. ISACA 2012, COBIT 5, p. 15.
66. ISACA 2012, COBIT 5, p. 13.
67. ISACA 2012, COBIT 5: A business framework for the governance and management of enterprise IT, www.isaca.org/COBIT/
Pages/COBIT-5-Framework-product-page.aspx.
68. ISACA 2012, COBIT 5, p. 69.
69. ISACA 2012 COBIT 5, Appendix G.
70. ISACA 2012, COBIT 5, p. 14.
71. ISACA 2012, COBIT 5, p. 14.
72. ISACA 2012, COBIT 5, p. 14.
73. Rubino, M & Vitolla, F 2014, ‘Internal control over financial reporting: opportunities using the COBIT framework’,
Managerial Auditing Journal, vol. 29, no. 8, pp. 736–71.
74. Rubino & Vitolla 2014.
75. Zororo 2014.
76. Juiz & Toomey 2015, p. 60.
77. Available at: http://infostore.saiglobal.com/store/details.aspx?ProductID=1390488.
78. Available at: http://infostore.saiglobal.com/store/details.aspx?ProductID=1696546.
79. ‘Gartner’s top 10 strategic tech trends for 2015’, www.information-management.com/gallery/gartners-top-10-strategic-tech-
trends-for-2015-10026168-1.html.
80. Carnegie, GD & O’Connell, BT 2014. ‘A longitudinal study of the interplay of corporate collapse, accounting failure and
governance change in Australia: Early 1890s to early 2000s’, Critical Perspectives on Accounting, vol. 25, no. 6, pp. 446–68.
81. Carnegie & O’Connell 2014, p. 461.
82. McNally, L, ‘Former Sydney Ferries boss Geoff Smith jailed for misusing work credit card on BMWs,
holidays and home renovations, ABC News, 25 August 2014, www.abc.net.au/news/2014-08-25/
former-sydney-ferries-boss-sentenced-to-jail-time-for-fraudulan/5694994.
83. ABC South East SA, ‘Million dollar fraud hits K&S Corporation for second time’, 26 February 2015, www.abc.net.au/local/
stories/2015/02/26/4187301.htm.
84. ‘Making companies pay for failing to prevent employee fraud’, The Conversation, 25 September 2014, http://theconversation
.com/making-companies-pay-for-failing-to-prevent-employee-fraud-31912.
85. Carnegie & O’Connell 2014, pp. 446–68.
86. COSO 2013, Internal control — Integrated framework, Executive Summary, May, www.coso.org/documents/990025P_
Executive_Summary_final_may20_e.pdf, p. 3.
87. COSO 2013, p. 3
88. Auditing and Assurance Standards Board 2015, Auditing Standard ASAE 3150 Standard on Assurance Engagements
Assurance Engagements on Controls, www.auasb.gov.au/admin/file/content102/c3/Jan15_ASAE_3150_Assurance_
Engagements_on_Controls.pdf, p. 12.
89. COSO 2013, p. 3.
90. Australian Accounting Standards Board 2007, Framework for the preparation and presentation of financial statements,
paragraphs 24–46, www.aasb.gov.au.
91. Australian Accounting Standards Board 2011, AASB 101 Presentation of financial statements, www.aasb.gov.au.
92. COSO 2013, p. 6.
93. Hubbard, LD 2003, ‘Understanding internal controls’, Internal Auditor, vol. 60, no. 5, pp. 3–25.
94. Auditing and Assurance Standards Board 2015, p. 55.
95. COSO 2013, p. 4.
96. COSO 2013, p. 7.
97. Auditing and Assurance Standards Board 2015, p. 55.
98. Rochfort, S, 2008, ‘Qantas grounds jets over soaring fuel bill’, The Age, 13 November, www.theage.com.au.
99. Drummond, M 2011, ‘CEOs become chief emergency officers’, The Australian Financial Review, 13 January, www.afr.com.

370 PART 2 Systems characteristics and considerations

100. Drummond 2011.
101. Drummond 2011.
102. Bajkowski, J 2011, ‘Tough questions over back-up’, The Australian Financial Review, 14 January, www.afr.com.
103. Smith 2011a, ‘Running an office, under water’, The Australian Financial Review, 1 February, www.afr.com.
104. Bajkowski 2011; Thompson, S & Garvey, P 2011, ‘Disaster recovery plans make a comeback’, The Australian Financial
Review, 18 January 2011, www.afr.com.
105. Bajkowski 2011.
106. Smith 2011b, ‘Disasters to boost cloud computing’, Australian Financial Review, 4 February, www.afr.com; Smith, P 2011a.
107. Smith 2011a.
108. Smith 2011a.
109. Bajkowski, J 2011, ‘Security standards go here, there and nowhere’, The Australian Financial Review, 22 March,
www.afr.com.
110. Colquhoun, L 2011, ‘CIOs and the cloud, a bet either way’, The Australian Financial Review, 8 November, www.afr.com.au.
111. Jay, C 2011a, ‘Cloud computing offers vital disaster back-up’, The Australian Financial Review, 29 July, www.afr.com.
112. Jay, C 2011b, ‘Watch your backup’, The Australian Financial Review, 4 November, www.afr.com.
113. Jay 2011b.
114. Smith 2011b; Noonan, K 2011, ‘Clear-headed on cloud’, The Australian Financial Review, MIS, 29 July, www.afr.com.
115. COSO 2013, p. 4.
116. COSO 2013, p. 7.
117. Auditing and Assurance Standards Board 2011, ASA 315, paragraph A88; Deloitte & Touche LLP 2003b, The growing
company’s guide to COSO, June, Deloitte & Touche LLP, New York, pp. 6–7.
118. Auditing and Assurance Standards Board 2015, p. 55.
119. COSO 2013, p. 5.
120. COSO 2013, p. 7.
121. Auditing and Assurance Standards Board 2011, ASA 315, Appendix 1, paragraph 5.
122. Auditing and Assurance Standards Board 2011, ASA 315 Appendix 1, paragraphs 5–8.
123. COSO 2013, p. 5.
124. COSO 2013, p. 7.
125. Auditing and Assurance Standards Board 2015, p. 55.
126. The Institute of Internal Auditors Australia 2015, ‘What is internal audit’, www.iia.org.au/aboutIIA/whatisinternalaudit.aspx.
127. Auditing and Assurance Standards Board 2015, p. 14.
128. COSO 2013, p. 7.
129. The Institute of Internal Auditors 2012, International standards for the professional practice of internal auditing (standards),
www.iia.org.au/technicalResources/knowledgeitem.aspx?ID=256.
130. COSO 2013, p. 12.
131. The Institute of Chartered Accountants in Australia 2007, ‘Understanding financial statement audits — a guide for financial
statement users’, Chartered accountants auditing and assurance handbook 2007, John Wiley & Sons, Brisbane, p. 4.
132. Auditing and Assurance Standards Board 2009, ASA 265 Communicating deficiencies in internal control to those charged
with governance and management, www.auasb.gov.au.
133. COSO 2012, Frameworks and appendices, Internal Control — Integrated Framework, p. 43.
134. Lipton, P & Herzberg, A 1995, Understanding company law, 6th edn, LBC Information Services, Sydney, p. 308.
135. Lipton & Herzberg 1995, p. 309.
136. Gay, G & Simnett, R 2000, Auditing and assurance: services in Australia, McGraw-Hill, Sydney, pp. 89–90.
137. Lipton & Herzberg 1995, p. 308.
138. ASX Corporate Governance Council, 2003, p. 7.
139. COSO 2013, Internal control — Integrated framework, Executive Summary, May, www.coso.org/documents/990025P_
Executive_Summary_final_may20_e.pdf, p. 3.
140. IT Governance Institute 2006, p. 22.
141. Auditing and Assurance Standards Board 2013, Auditing Standard ASA 315 Identifying and assessing the risks of material
misstatement through understanding the entity and its environment, paragraph A124, www.auasb.gov.au/admin/file/
content102/c3/Nov13_Compiled_Auditing_Standard_ASA_315.pdf.
142. Auditing and Assurance Standards Board 2013, Auditing Standard ASA 315, paragraph A37.
143. Relating the COSO Internal control — Integrated framework and COBIT 2014, An ISACA COBIT Series White Paper,
www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Relating-the-COSO-Internal-Control-Integrated-
Framework-and-COBIT.aspx.
144. Relating the COSO Internal control — Integrated framework and COBIT 2014.
145. Bhimani, A & Soonawalla, K 2005, ‘From conformance to performance: the corporate responsibilities continuum’, Journal of
Accounting and Public Policy, vol. 24, p. 169.
146. Pavel Castka, P, Bamber, CJ, Bamber, DJ & Sharp, JM 2004, ‘Integrating corporate social responsibility (CSR) into ISO
management systems — in search of a feasible CSR management system framework’, The TQM Magazine, vol. 16, no. 3,
pp. 216–24.

CHAPTER 8 Internal controls I 371

147. Rio Tinto 2009a, ‘Engagement’, www.riotinto.com; Rio Tinto 2009b, ‘Human rights’, www.riotinto.com; Kapelus, P
2002, ‘Mining, corporate social responsibility and the “community”: the case of Rio Tinto, Richards Bay Minerals and the
Mbonambi’, Journal of Business Ethics, vol. 39, pp. 275–96.
148. COSO 2013, p. 5.

ACKNOWLEDGEMENTS
Figures 8.2 to 8.6: © ISACA.
Figure 8.7: © COSO materials.
Figure 8.8: Copyright Agency Limited.
Figure 8.1: © Productivity Commission.
Photo: © nyul / iStockphoto.

372 PART 2 Systems characteristics and considerations

CHAPTER 9

Internal controls II
LEA RNIN G OBJE CTIVE S

After studying this chapter, you should be able to:

9.1 explain the importance of control activities in the accounting process
9.2 evaluate internal controls as general or application
9.3 evaluate controls relating to the stages of data processing and COSO and COBIT
9.4 describe the aims of a computerised accounting information system
9.5 explain and provide examples of general controls
9.6 explain and provide examples of application controls
9.7 evaluate the operation and components of a disaster recovery plan
9.8 critique the execution of control activities
9.9 demonstrate the different techniques for documenting a control system
9.10 evaluate the effectiveness and limitations of a control system.
Introduction
The internal control system fits within the wider corporate governance framework of an organisation.
The design of an internal control system should provide reasonable assurance regarding the achievement
of objectives relating to operations, reporting and compliance. Achieving internal control objectives
requires the consideration of five integrated control components: control environment, risk assessment,
control activities, information and communication, and monitoring. This framework was introduced as
the COSO Internal Control Framework.
In this chapter we focus on the control environment and control activities components of the
COSO model, introducing some examples of the types of control activities and the various classifi-
cation schemes that can be applied to internal controls. We also discuss in more detail how controls
relate to the operation of business processes and the accounting function. Business processes are a
group of tasks that achieve a specific organisational goal or objective. What emerges from the dis-
cussion of business processes and the description of internal control systems is the reality that busi-
ness processes will not necessarily operate as expected. As a result, management needs to have in
place means of dealing with the risk of errors or irregularities in their business processes. This is
where control activities play a role, aiming to prevent, detect or correct such errors or irregularities.
The material covered in this chapter is oriented towards for-profit organisations, with the
examples typically set in this context. However, other organisations, for example not-for-profit and
community-based organisations, have an equal need for internal controls, as they also face risks
that inhibit the attainment of their objectives. As such, the material we cover in this chapter applies
broadly to different types of organisations.

374 PART 2 Systems characteristics and considerations

9.1 Control activities, business processes and
accounting
LEARNING OBJECTIVE 9.1 Explain the importance of control activities in the accounting process.
In conceptualising accounting, business processes and internal controls it is useful to think of the finan-
cial reporting process and the possibility of errors occurring in that process. While the scope of internal
controls extends beyond the domain of the financial reporting process, commencing from the accounting
process and branching out will allow you to start from a basis you are familiar with.
Financial statements make a series of assertions about the events that have taken place and the bal-
ances that are presented. As outlined in the previous chapter, the ASAE 3150 risk assessment process
includes whether the entity has a process for: (i) identifying risks which threaten achievement of control
objectives; (ii) estimating the significance of the risks; (iii) assessing the likelihood of their occurrence;
and (iv) deciding about actions to address those risks.1
Assertions are implicitly or explicitly made regarding the recognition, measurement, presentation,
disclosure or compliance of the subject matter, which reflects the overall objectives of the system. These
assertions relate to the following.
a) Transactions, activities and events over a period, including (i) occurrence; (ii) completeness;
(iii) accuracy; (iv) cut-off and (v) classification.
b) Volumes, amounts or balances as at a date, including (i) existence; (ii) rights and obligations;
(iii) completeness; and (iv) valuation and allocation.
c) Presentation and disclosure in a report: (i) occurrence and rights and obligations; (ii) completeness;
(iii) classification and understandability; (iv) accuracy and valuation; and (v) consistency.
d) Performance of the system: (i) economy; (ii) efficiency; and (iii) effectiveness.
e) Contractual obligations of a service organisation, providing IT, online or cloud services for virtual
processing of information, communications or data and storage of data or information, over a period:
(i) security; (ii) confidentiality; (iii) privacy; (iv) accessibility and availability; and (v) data integrity,
including: completeness; accuracy; timeliness; and authorisation.2
For example, the assertion of completeness requires that all transactions are recorded. The assertion
of existence requires that all assets reported actually exist. The assertions lead to the identification of
the source of risks that could compromise the assertions. For example, completeness is threatened if not
all sales transactions are recorded. The other important consideration is that not all risks are financially
based. There will be some risks (e.g. unauthorised access to computing facilities) that may not necess-
arily directly impact on the financial statements.
Once an organisation has identified a source of risk, the next step is to evaluate the extent of the risk.
For example, let’s assume the simple example of a sales process requiring that a sales order form be
filled in, with this form stored until the end of the day. At the end of the day the form is entered into the
computer and the sales and accounts receivable balances are updated.
If we now think about the risks involved in this process, or what could go wrong, perhaps surprisingly,
given the somewhat simple nature of the process, there are several areas for potential errors. These include:
1. incorrect details being recorded on the sales order form
2. the sales order form being lost or damaged
3. the sales order form data being entered incorrectly, for example, the quantity of 10 being input as 100
4. accounts receivable and sales data being updated incorrectly, for example, the computer posting data
to the wrong location or recording transactions twice
5. the computer system not being available
6. unauthorised people accessing the computer and entering transactions, either incorrectly due to lack
of knowledge of the process, or falsely, for motives of fraud or personal gain.
From our small business process example we have asked what could go wrong and have come up with six
potential threats to the recording and processing of the sales order form. Let us now think about how these

CHAPTER 9 Internal controls II 375

errors relate to the financial statement assertions. Let’s assume that two sales order forms have been filled in
correctly but one has been lost and the other has been entered incorrectly into the computer. This means that
there is one sale that will not be recorded. As a result, we immediately have a concern about the sales figure
that will be contained in the financial statements since it will not include all sales made. We will also have con-
cern about the valuation of accounts receivable and inventory, since accounts receivable will be understated
(a credit sale has not been recorded) and inventory will be overstated (inventory that has been sold has not been
removed from the records). With the incorrectly entered form, let’s assume that the quantity sold was keyed in
as 78 instead of 67 units. As a result of this error, the sales figure will be higher than it should be (accuracy of
sales figure is threatened), accounts receivable will be higher than it should be (the valuation of the asset will
be incorrect) and inventory will be lower than it should be (again, the valuation of the asset will be incorrect).
From these two examples, we can see how an error in a business process can impact the financial state-
ments. However, it is not only financial statement errors that internal controls are concerned with. As
accountants and auditors you will likely primarily be exposed to the financial statement perspective, but you
should also be aware of the environment in which the financial statements are generated and think also in
terms of the risks that do not directly impact on the financial statements; for example, someone gaining unau-
thorised access to the physical computing resources of the organisation or the installation of unlicensed soft-
ware on the computer system. Regardless of the nature of the risk, the approach in progressing through this
chapter should be to assess the assertions relating to transactions, amounts, presentation and disclosure in
reports, performance of the system and contractual arrangements of the service organisation.
After identifying risks, management will decide on appropriate policies and procedures to address the
risks. These policies and procedures are called control activities, and will be communicated to the organ-
isation for implementation.

9.2 Evaluation of control activities

LEARNING OBJECTIVE 9.2 Evaluate internal controls as general or application.
From the COSO framework introduced in chapter 8 we saw that one of the components of the internal con-
trol system was control activities. In this section, we take a look at some examples of control activities and the
different ways in which they operate. As a starting point we look at the classification provided by Australian
Auditing Standards. Financial statement auditors use the auditing standards as a basis for planning and carrying
out external financial statement audits with the aim of detecting any material misstatements in the financial state-
ments. The auditor’s concern, therefore, is primarily with the financial accuracy of the statements. However, note
that, while the auditing perspective provides us with a basis for our controls, for an accountant working with an
accounting information system within an organisation, the concern extends beyond financial to non-financial
risks and controls. Australian Auditing Standard ASA 315 Identifying and Assessing the Risks of Material Mis-
statement through Understanding the Entity and Its Environment3 classifies controls into five types:
1. authorisation
2. performance reviews
3. information processing controls
4. physical controls
5. segregation of duties.
This perspective on control activities focuses on the risk areas/activities within the organisation and
emphasises a functionalist perspective — what happens within the organisation and how the controls
operate. These control areas should be remembered, since for each one we will see different examples
of specific control activities.
Authorisation is concerned with the activities and procedures put in place to reasonably assure
that the transactions and events occurring are carried out by those with the appropriate authority and
that such events have been appropriately approved prior to execution. In other words, it aims to set
defined roles and responsibilities for individuals within the organisation as well as having mechanisms
for ensuring that these are adhered to. Examples of authorisation procedures in action could include

376 PART 2 Systems characteristics and considerations

checking a customer’s credit limit before proceeding with a credit sale, or gaining a manager’s approval
before making an unusually large purchase or an irregular purchase.
Performance reviews are those activities that involve some form of review or analysis of perfor-
mance, typically looking to compare actual outcomes with those that were expected or planned. The
classic accounting example is the comparison of actual and budgeted figures and the conduct of variance
analysis to determine the source of the variance. Other types of performance reviews could include com-
paring two sets of data to see if they match (e.g. a bank reconciliation, which compares bank records to
business records to ensure parity between the two).
Information processing controls are those that are put in place within the organisation to work towards
the accuracy, completeness and authorisation of transactions. Accuracy is the aim of making sure that all
data that enters the system are correct and reflect the actual events that are being recorded. Completeness
refers to the aim of ensuring that all events that occur are recorded within the system. Authorisation, as
described above, is concerned with whether or not the events that occur are appropriately approved before
being executed. Information processing controls can be classified as either general or application controls.
General controls are ‘policies and procedures that relate to many applications and support the effec-
tive functioning of application controls’.4 General controls operate across the organisation and relate to the
overall environment in which different information systems are located. Note from the definition that general
controls do not relate to a specific application or process and, as a result, will not directly affect the operation
of the different information systems that may exist within the organisation. General controls may provide a
suitable environment in which separation of duties and restricted access to resources can be applied, but they
do not help to control the actual operation of the different computer systems that the organisation uses. As
such, general controls provide the environment within which application controls operate.
Application controls ‘are manual or automated procedures that typically operate at a business pro-
cess level and apply to the processing of transactions by individual applications’.5 As this definition
indicates, application controls are designed around the control objectives of a specific business process
or system (e.g. the sales process, ordering process, manufacturing process or cash receipts process) and
relate to processing within individual applications. That is, application controls are specific to a par-
ticular business process in that they will be implemented to address the risks and threats unique to that
process. Application controls operate within the scope of general controls. In a computerised environ-
ment, application controls will typically be classified as input, processing or output. We will look at fur-
ther examples of these as we progress through this chapter and in chapters 10 to 12 when we examine
the different business processes or transaction cycles within the organisation.
As the name suggests, physical controls refer to those controls that are put in place to physically pro-
tect the resources of the organisation, including protecting them from the risk of theft or damage. These
will be discussed in more detail later in the chapter.
Segregation of duties refers to the concept that certain key functions should not be performed by the
same person. The typical reference point within a business process is that record keeping (person who
records a transaction), execution (person who performs a transaction), custody (person in possession of
the assets involved in a transaction) and reconciliation (person reconciling transaction data) should be
separated. Segregation of duties also applies across the IT systems within the organisation. These con-
cepts will be discussed further later in the chapter.
These alternative classifications of controls are by no means in conflict. Rather, they represent the
numerous perspectives that can be taken when analysing internal controls.
Controls may also be classified based on how they deal with risk and where in the information pro-
cessing activities they operate. These include classifications of preventive/detective/corrective controls
and input/processing/output controls.

Preventive, detective and corrective controls

Control activities can be broadly classified as preventive, detective or corrective. This classification
views control activities based on how they deal with the risks that confront the organisation — do they
stop the risk from materialising, detect when a risk has materialised or remedy the situation after the

CHAPTER 9 Internal controls II 377

risk has come to fruition? The obvious preference is for preventive controls — those that stop all risks
from occurring. However, this is not always possible. That is, some risks will not be anticipated and, as
a result, no preventive strategies will have been put in place. Further, it may not be possible to prevent
or detect some risks, leaving corrective controls (i.e. fixing the problem after it has occurred) as the only
option. An example would be recovering from a data breach from hacking.
For some risks, even if we anticipate their occurrence, we may not put in place control activities to
address them. This is based on the cost–benefit concept, which requires that the benefit obtained from a
control activity (i.e. the expected value of the loss) should exceed the cost of putting the control activity
in place. An example of the cost–benefit concept can be seen from shopping at the supermarket. One risk
that the supermarket wants to address is that of inaccurate prices being charged to customers. To deal
with this, barcode scanners are used to record sales data and checkout registers automatically calculate
the amount owed by the customer. But what if the scanner gets an item wrong? Or what if an item is
scanned but not recorded by the register? This could be dealt with by having a second person scanning
the groceries and comparing the original total to the second total. If the totals agree, the supermarket
can be confident that all goods have been recorded in the sale and recorded at the correct amount. How-
ever, supermarkets do not perform this secondary process; they are happy to rely on the items being
scanned by one person or the customer themselves at self-service checkouts. Why? First, the probability
of an item scanning incorrectly would be assessed as low. As a result, the expected amount to be saved
by implementing the control would be minimal, at best. Second, the cost of implementing this con-
trol would be significant; checkout register numbers would have to be doubled to handle the increased
scanning requirements and still process customers through the checkout promptly. This would require
additional technology and labour. In addition, customer dissatisfaction from slower sales processing
could lead to loss of business. In this case, the benefits of the control do not exceed the costs, particu-
larly as new technologies are changing business processes in supermarkets as self-service checkouts are
used more frequently.
Preventive controls
Preventive controls are designed to stop errors or irregularities occurring. As a simple example, an
employee may try to enter an employee number in the system as ‘A1234’. If organisational practice is that
all employee numbers have six digits and contain no alphabetic characters, allowing the input of ‘A1234’
will cause problems because it is an invalid and nonexistent identification number. A properly designed
input control (discussed later in the chapter) will detect this anomaly in the input and alert the person per-
forming the data entry, prompting them to correct the input, or at the very least not allow the input to be
accepted. This is an example of a control preventing data errors from entering the system. Similarly, a
password is a preventive control because it stops unauthorised users from gaining access to a system. An
example that you may be familiar with from your use of the internet is the use of required fields — fields
that must be filled in before you can progress to the next screen when creating an online account or making
an online booking. Required fields are preventive because they stop the progress of the transaction until all
the required data has been provided and therefore prevent incomplete data being gathered.
Alternatively, think of the example of a firewall that protects a computer or network. New viruses are
constantly being developed, leaving virus protection developers in a constant race to protect computer
users. Installing a firewall is an example of a preventive control — it provides a shield around the com-
puter or network that stops unauthorised users or programs from gaining access to the network. That is,
it stops known threats from occurring.
Detective controls
Unlike preventive controls, detective controls will not prevent errors from occurring. Rather, the func-
tion of a detective control is to alert those involved in the system when an error or anomaly occurs.
So, as the name suggests, it detects errors or anomalies. An example is the use of a virus scan program
to check for computer viruses. Running a virus scan analyses the computer or network and identifies
viruses that may have penetrated the firewall. Once these are identified, their existence will be reported.

378 PART 2 Systems characteristics and considerations

In this case, the threat (a new virus) was not stopped (it entered the network) but was detected within the
system, allowing for follow-up action (e.g. quarantine of the file, repair of the file or deletion of the file).

Corrective controls
Corrective controls are designed to correct an error or irregularity after it has occurred. Examples
include the organisation’s disaster recovery plan, which aims to restore the business to an operating pos-
ition after the occurrence of a disaster, and the use of virus protection software to remove a virus that has
corrupted computer programs within the organisation. In some cases, even if the organisation has a fire-
wall in place (preventive control) and carries out regular system scans (detective control) virus attacks
may still occur. For example, if the virus definitions on a scan program are not up to date, a virus will
not be known until it has caused damage to data or network operation. The only way to recover from the
attack is to correct the situation, typically by restoring the system using a backup. Note that a corrective
control comes into effect after the error or irregularity has occurred.
This classification scheme of preventive, detective and corrective controls can be applied to both
general and application controls.

AIS FOCUS 9.1

Insider trading: the worst case in Australia?

The importance of controls is illustrated by the fraud committed by an Australian Bureau of Statistics
(ABS) employee and a National Australia Bank (NAB) employee between 12 September 2013 and 8 May
2014. Supreme Court Justice Elizabeth Hollingworth said that it was the worst case of insider trading to
come before the courts. Justice Hollingworth noted in her judgement that, ‘For both of you, your motiv-
ation for committing these offences was personal greed, pure and simple’.6
Lukas Kamay and Christopher Hill first met in 2007 studying economics at Monash University in
Melbourne, Australia. The two men graduated in 2011. Kamay worked for NAB in the position of
associate director on the wholesale foreign exchange desk. Hill obtained a position with ABS in Can-
berra as an analyst in the time series analysis section. Hill’s responsibility was to analyse data for
monthly data figures. However, Hill had access to ABS data that was not necessarily directly related
to his position. The two friends kept in contact and in 2013 both attended a party where they first dis-
cussed sharing data for the purpose of insider trading. At a meeting at a pub in 2013 they agreed to use
the information to make $200 000 that they would split between them.
Hill took handwritten notes from unpublished labour force, new capital expenditure, retail trade and
building approvals data, and sent this information to Kamay’s mobile phone. Kamay then used this
information for trades in foreign exchange derivatives via two trading accounts. Kamay was careful to
ensure there were some losses to give the appearance of normal trading.
Kamay made a gross profit of more than $8 million and a net profit of more than $7 million. Hill was
unaware of the extent of the fraud because Kamay opened trading accounts that Hill was unaware of
(Hill received less than $20 000). Kamay and Hill were arrested in May after a four-month joint Australian
Federal Police (AFP) and Australian Securities & Investments Commission (ASIC) investigation following
a tip-off from a stockbroker about the link between the pair.7
A report by the Association of Certified Fraud Examiners (ACFE) found that tips are consistently and
by far the most common detection method. Over 40 per cent of all cases of fraud are detected by a
tip-off, twice the rate of any other detection method. The report also found that employees accounted
for nearly half of all tips that led to the discovery of fraud.8
Justice Hollingworth argued that insider trading uses inside information to gain an unfair advantage
over other traders in the market and that it is a form of cheating or fraud. That is, insider trading is a
serious criminal offence because it can undermine the integrity of markets and diminish public confi-
dence in the commercial world.9
Kamay pleaded guilty to money laundering, identity theft and insider trading. Hill pleaded guilty to
insider trading and misuse of public office. The consequences for both included jail terms. Kamay was
sentenced to seven years and three months in prison with a minimum term of four and a half years. Hill
was sentenced to three years and three months with a minimum term of two years.10

CHAPTER 9 Internal controls II 379

Input, processing and output controls
Another classification refers to where the control activity fits in the information processing stages of
gathering, using and transforming data. The type of controls we see at input, processing and output
within a business process relate specifically to the operation of that business process and are designed
based on the particular risks present within the process. Therefore, they are application controls. You will
see examples of these in the transaction cycle chapters.
Input controls are designed to operate as data enters the system. These controls typically aim to provide
reasonable assurance about the accuracy, validity and completeness of data being entered. Processing con-
trols are put in place to work towards the correct handling of data within the information processing stages. An
example of the types of issues that processing controls address is making sure that data is correctly updated in
the various data stores, and making sure that all sales are posted to accounts receivable at the right amounts.
Output controls are concerned with the various outputs generated by the process, and are focused on issues
such as who can request outputs, how outputs are prepared and making sure all outputs are accounted for.

9.3 COSO, COBIT and control activities

LEARNING OBJECTIVE 9.3 Evaluate controls relating to the stages of data processing and COSO and COBIT.
The COSO framework for internal control introduced in the previous chapter provides a general frame-
work for the assessment of effectiveness of internal controls over financial reporting (ICFR). COSO is
the framework used by most US organisations as well as organisations around the world to meet their
responsibilities under the US Sarbanes–Oxley Act (SOX) to maintain a system of ICFR.11
COBIT 5.0, a system of governance and internal control in a technology environment, was released by
ISACA in 2012. As discussed in the previous chapter, COBIT 5.0 is a framework for the governance and
management of enterprise IT. COBIT 5.0 assumes the design and implementation of automated application
controls to be the responsibility of the IT department. The COBIT IT processes cover general IT controls, but
only the development aspects of application controls.12 The six COBIT 5.0 application controls are as follows.
•• AC1 Source Data Preparation and Authorisation
Source documents should be prepared and authorised by appropriately qualified employees using
established procedures. The established procedures include appropriate segregation of duties and con-
sideration of good form design to minimise errors. Error and irregularity detection processes should
be in place. Processes for error and irregularity detection should be detected and corrected.
•• AC2 Source Data Collection and Entry
Qualified employees should ensure the timely data entry of transactions. If data is found to be incor-
rect, the same level of qualified employee should ensure the quality of data entry.
•• AC3 Accuracy, Completeness and Authenticity Checks
Such checks should ensure that transactions are accurate, complete and valid. Data that is input should
be validated. Any errors should be corrected as close as possible to the point of origin.
•• AC4 Processing Integrity and Validity
Integrity and validity of the data should be maintained throughout the processing cycle. The detection
of erroneous transactions should not disrupt the processing of valid transactions.
•• AC5 Output Review, Reconciliation and Error Handling
Procedures and associated responsibilities should be established to ensure that output is handled in
an authorised manner, delivered to the appropriate recipient and protected during transmission; that
verification, detection of errors and correction of the output occur; and that information provided in
the output is accurate and usable.
•• AC6 Transaction Authentication and Integrity
Before passing transaction data between internal applications and business/operational functions (in
or outside the enterprise), it should be checked for proper addressing, authenticity of origin and integ-
rity of content. Authenticity and integrity during transmission or transport should be maintained.13

380 PART 2 Systems characteristics and considerations

 An auditor will identify and test input controls, processing controls, output controls and interface con-
trols. In each of these stages there are certain key aims. For example, when authorising a transaction, rel-
evant documentation needs to be prepared, the documents need to be approved, and the documents need
to be collected and stored. For each of these activities there are control issues that need to be addressed.
These are analogous to the risks that we mentioned earlier; for example, when inputting data into the
system a control issue or risk is that of inaccurate or invalid data being entered.
Table 9.1 provides some examples of aims, control issues and controls, which are addressed by specific
control activities. Note that this list is by no means exhaustive. Referring back to this table as this chapter
progresses, as well as when looking at the transaction cycles in later chapters, can guide you in identifying
the main steps that occur, the issues to be aware of and the typical controls that can be applied to deal with the
issues. Keep in mind, however, that controls cannot be applied using a one-size-fits-all approach — some of
the controls in the table will work in some cases; in other scenarios they may not apply. Understanding the
operation of the business process is imperative in correctly identifying and applying internal control ideas.

TABLE 9.1 Control issues at various data processing stages

Aim Control issues Example of controls

Document preparation Is data gathered accurately? Preformatted documents.
Review of documents.
TRANSACTION AUTHORISATION

Authorisation to Was the preparer authorised to prepare the Job descriptions defining responsibility.
prepare documents document? Segregation of preparation and approval
Are prepared documents reviewed? responsibilities.
Review of prepared documents.
Restricted access to blank source documents.
Document collection Are source documents complete? Prenumbered documents.
Accurate? Sequence checks.
Are all source documents accounted for? Batch totals.
Are source documents moved through the Cancelling source documents after completion
process in a timely manner for input into of transaction.
the system?
Document storage Are documents kept to allow preservation of an Maintenance of secure storage systems.
audit trail?
Are documents kept for required legal time frame?

Authorised entry Is the person entering the data authorised to? Job descriptions defining responsibility.
System access controls.
Login procedures.
Defined user privileges.
Time-out after inactivity.
Separation of duties.
Data entry and data file maintenance or update.
Checking for Does the system check for accuracy? Edit checks.
DATA INPUT

accuracy, Does the system check for completeness? Reasonableness.

completeness and Does the system check for validity? Range checks.
authorisation When is the data gathered and entered? Limit checks.
Logic checks on entered data.
Redundant data check.
Completeness checks.
Required fields.
Batch totals.
Reconciliation of transactions entered and
transactions processed.
Capture data at its point of origin.
Turnaround documents.
Use of a standard chart of accounts.
(continued)

CHAPTER 9 Internal controls II 381

 TABLE 9.1 (continued)

Aim Control issues Example of controls

Integrity Is processed data verified as being correct? Run-to-run totals.
DATA PROCESSING

Are checks in place to ensure data updates Batch totals.

have occurred correctly? Comparison of source documents to updated
data files.
Sequence checks.
Processing error logs.

Storage How long is output stored for? Defined policies for the storage of outputs.
Where is output stored? Defined policies for the distribution of
What privacy and security issues impact on the documents.
treatment of outputs?
DATA OUTPUT

Access Who can access the outputs? Printing to secure locations for sensitive material.
Defined user privileges for accessing or printing
outputs.
Defined job descriptions or role responsibilities
that specify required outputs.
Checking Are the outputs accurate? Reconciliation of outputs to source data.
Is an adequate audit trail maintained? Reconciliation of subsidiary and control
Are procedures in place for any detected errors? accounts.
Reliability Is the data accurate? Confirmation of details with third parties.
EXTERNAL DATA

Is the data valid? Within firm authorisation (e.g. credit checks for
Is the data complete? sales orders received by email).
Checking that the third party (supplier or
customer or creditor) is known to us.
Use of existing customer or supplier or credit
data to confirm existence.
Use of turnaround documents.

9.4 Aims of a computerised accounting

information system
LEARNING OBJECTIVE 9.4 Describe the aims of a computerised accounting information system.
Any computerised system should aim to ensure transactions are properly authorised, recorded and pro-
cessed in their entirety in a timely manner.

Proper authorisation
The aim of proper authorisation is to ensure that transactions are executed by those people with the appro-
priate authority, and that any modifications to the data in the system are performed by the appropriate
authorised person. As an example, a retail company policy may state that all credit sales up to the value of
$1000 can be approved by regular sales staff, but for credit sales exceeding the value of $1000, the author-
isation of the supervising accounts receivable manager must be obtained. The aim of the system in this
scenario would be to ensure that, if a credit transaction valued at more than $1000 occurs, it must have the
appropriate approval of the manager. That is, the transaction must be authorised. Authorisation in a com-
puterised information system can be established through user privileges and access rights and by placing
restrictions on what different users are able to do within the system. In a manual paper-based system, such
a control could work by requiring that sales invoices for credit sales over $1000 are manually approved and
signed by the supervising accounts receivable manager before being cleared for shipment.

382 PART 2 Systems characteristics and considerations

 Authorising a transaction implicitly says that the transaction is valid. When referring to a transaction as valid
we mean the transaction actually occurred and the parties involved in the transaction actually exist. Part of the
authorisation process will thus be concerned with verifying the bona fide nature of the transaction or event.

Proper recording
Proper recording of transactions is essentially about accuracy. Accuracy is concerned with making sure that
all data that enter the system are in the correct format and of the right type, and that the data gathered accu-
rately reflect the reality of the underlying transaction or event. For each authorised transaction or event, the
organisation needs to ensure that these events are accurately recorded. As an example, if the data field for staff
numbers on a database is preformatted to contain only six numerals, then it should not be possible to enter a
staff number that contains alphabetic characters or numbers with five or seven digits. It should also require that
staff numbers entered be valid; that is, that an employee within the organisation actually has the staff number.
Ways of doing this are discussed later in this section. Accuracy, as a general principle, can include paper and
automated aspects of capturing and recording data. Focusing specifically on the entry of data into the com-
puter, input accuracy is the aim of ensuring that all data entered into the system are correct at the source.
The accuracy objective is very closely linked to the assertions of accuracy and valuation. That is, if
the data are not gathered and recorded correctly, the financial statements generated cannot be an accurate
reflection of the events that have transpired.

Completeness
Completeness can refer to both inputs to the system and transactions handled by the system. Input com-
pleteness is the aim of ensuring all transaction events and all required data relating to those events are
captured within the system. For example, if a sales order form requires a salesperson ID number to be
entered, a system should not allow the transaction to progress until the ID number is entered. Note that
input completeness operates at two levels. First, it operates to ensure that all details for an individual trans-
action are captured. This is completeness at the level of the individual transaction. Second, more generally,
it must also be ensured that all transactions are captured. This is completeness at the business process level:
ensuring all activities within the process are recorded. For example, a sales process that omits data on some
of the transactions is undesirable because reports and information generated about that process would be
inaccurate on account of their not being based on all of the transactions that occurred. The completeness
objective is closely linked to the assertion of completeness, which, from a financial statement perspective,
requires that all transactions and accounts that should have been recorded have actually been recorded.

Timeliness
The goal of timeliness works towards ensuring that data are captured, processed, stored and made accessible
in the most time-effective manner to enable the production of useful information for system users. Timeliness
for an information system does not necessarily mean that all transactions must be processed immediately,
rather that they should be processed to suit the needs of the organisation. Options for the processing of data
include batch processing, online real-time transaction processing, and online gathering delayed processing.
Batch processing operates by accumulating transactions in a group or batch and then processing
the group of transactions together. Batch processing can have several advantages for an organisation,
including efficiency in processing transactions and fewer system demands during regular operations.
However, it also means that data are not immediately updated after each transaction. Taking a retail
firm as an example, this would mean sales accumulate and would be processed together at the end of
the day. Any queries made during the day about stock levels for items of inventory would not take into
consideration sales that had occurred since the last batch process run. Thus, the information would be
slightly inaccurate. For some organisations this delay in processing is not necessarily a problem. How-
ever, moving from a retail store to an airline booking system, it can be seen that batch processing is
not always ideal. This leads to the second processing option: online real-time data processing. As the

CHAPTER 9 Internal controls II 383

name suggests, this processes data from transactions as they occur. Environments where this approach is
needed are where immediate up-to-date information is required for decision making and effective busi-
ness operations. An example could be an airline. Think of the booking process that it goes through with
its passengers and the type of information that it requires when handling a booking. It is obviously infea-
sible for an airline to say to a customer ‘We think we have a seat available on that flight’. The customer
needs to know this information when they make the booking. This requires an information system that
is immediately updated with each transaction. Imagine the problems airlines would have if they operated
under a batch processing environment — the potential issue of double booking seats could cause night-
mares for the airline, not to mention the passenger who has to share a seat with someone!
A compromise between online real-time processing and batch processing is online data gathering and
batch processing. It has aspects of both systems in its design. As transactions occur they are immediately
stored by the system — this is the online component. However, related data files are not updated until the
end of the day or the end of some designated interval, at which time all transactions that have occurred and
been stored will be processed in the system. An example could be a sales system where the details of sales
are captured electronically as they occur. This sales data will then be stored until the close of business. At
the close of business, all of the sales that have occurred throughout the day will appear in the file and be
processed through the system — updating the accounts receivable data, customer data, inventory data and
so on. So while data are gathered in real time, they are processed in batches.
Within the framework for analysing and classifying controls, we now turn our attention to some
specific examples of control activities. The discussion will cover the operation of the control as well as,
where appropriate, flowcharts for how the control will look in a systems flowchart, and a classification
as preventive/detective/corrective or input/processing/output.

9.5 General controls

LEARNING OBJECTIVE 9.5 Explain and provide examples of general controls.
General controls are those that relate across all the information systems in an organisation. They include
physical controls, segregation of duties, user access, systems development procedures, user awareness of
risks, and data storage procedures. Each of these will be discussed in this section.

Physical controls
Physical controls are concerned with restricting access to the physical resources of the organisation.
At the most obvious level, the concern would be who has physical access to the organisation’s com-
puting resources. Especially for organisations that have large data processing centres that handle all of
the transactions and information processing requirements of the organisation, the risk of unauthorised
people accessing and damaging (accidentally or otherwise) the physical infrastructure is one the organ-
isation is not prepared to take. As a result, organisations will employ a range of physical controls to
restrict physical access, including the following.
•• Locked computing premises. Locking facilities and restricting the distribution of keys to the facility
works in two ways. First, locked premises means that unless you have a key you are unable to gain
access. Second, if the distribution of keys is controlled it is possible to narrow down the people
who may have entered the premises at a particular time. Locking premises is primarily a preventive
control — it stops unauthorised access to the premises.
•• Discrete premises that do not attract attention. Discrete premises can be a consideration when
choosing the location for data processing and technology headquarters. Organisations that do not
advertise the location of their information technology centres are theoretically less exposed to targeted
attacks on the organisation’s physical resources.
•• Swipe card access. Controlling physical entry to buildings and office facilities through the use of swipe
card access means only those with a swipe card will be able to gain access. Swipe card technology
also allows for the recording of data about who enter the premises and at what time.

384 PART 2 Systems characteristics and considerations

•• Biometric access controls. A limitation of swipe cards is that the person with the card may not
necessarily be the person who is meant to have the card, since swipe cards may be lost, stolen or
loaned. A way to overcome this is through the use of biometric controls, such as fingerprint swipes
or retina scans. The benefit of this technology is that biometric identification, unlike swipe cards or
passwords, ensures that the person gaining access is actually authorised to do so.14
•• Onsite security. The presence of onsite security, such as a manned front desk, can be an effective
means of restricting unauthorised people from accessing a building.
•• Security cameras to record access to the premises. The presence of security cameras can act as both a
preventive and a detective access control. From a preventive perspective, if people know cameras are
there they are less likely to attempt unauthorised access. Additionally, if the cameras are present they
can provide a means of detecting unauthorised access.
An example of a physical control would be a locked storeroom for inventory items, or restricted access
to the computer processing centre. In addition, physical controls over key source documents are an impor-
tant consideration. Probably the best example in this category is the storage of blank cheques. A sound
physical control would see cheques stored in a locked location with access limited to a small number of
people. Further, a person with access to the blank cheques should not have the power to authorise (sign
and approve) cheques, since this creates the risk of cheque misappropriation. Physical controls over
cash and inventory are also important. Occupational fraud is an issue that confronts organisations glob-
ally. A report by the Association of Certified Fraud Examiners (ACFE) found three broad occupational
fraud categories: asset misappropriation, corruption and financial statement fraud. The report found asset
misappropriation, where an employee steals or misuses an organisation’s resources (for example, theft
of company cash, false invoices, cheque tampering or inflated expense accounts) accounted for 85 per
cent of the cases analysed. The median cost was $130 000 per incident.15 In Australia, PwC found that
57 per cent of respondents reported experiencing economic crime. The number is concerning because it
is higher than the global (37 per cent) and Asia Pacific (32 per cent) average.16

Segregation of duties
When we look at the operation of the different transaction cycles in chapters 10 to 12 we will see that the
recording, execution, custody, authorisation and reconciliation functions should be performed by different
individuals. When looking at IT systems, separation of duties is equally important. Within the IT func-
tion, separation of duties should exist between the users of IT, the maintainers of the IT systems, system
designers, system testers and those with access to the data within the systems. The rationale behind this is
that combining any of these roles creates a conflict for the individual, places the organisation’s resources
at risk and enables an individual to carry out fraud without being detected. For example, if the person
designing and testing a new application also has access to the organisation’s data resources there is the
possibility that the live data could be used in the testing process. This exposes the data to the risk of
damage or corruption if the testing does not work as expected. Alternatively, if users are also involved in
the design of programs there is the risk that, because of their intimate knowledge of how the program was
developed, they will be able to work around any controls that may have been built into the program.

User access
The area of user controls predominantly relates to the logical access of users to the systems within
the organisation. The primary example in this area is the use of passwords to restrict system access to
authorised users17 by allocating users a unique identification code that only they are aware of, which is
one of the most common access control methods in operation.18 Organisations requiring users to have
passwords need to consider the following aspects of password operation.
Format of the password
Increased sophistication in the development of algorithms and programs designed to break passwords
means that password strength becomes an important issue. The strength of the password is related to its

CHAPTER 9 Internal controls II 385

length and format. For example, a password that is set as ‘CAT’ would be much easier to crack than a
password that has been set as ‘C@9at12#’. Increasingly, online sites that require passwords will provide
indicators of password strength, with many advocating a mix of alphanumeric characters, upper and
lower case characters and symbols.
A step beyond this is to have the system automatically generate a password for the user, which will
ensure that password format protocols are adhered to on a consistent basis. The trade-off with this option
is that system-generated passwords may be more difficult for users to remember, leading to the tendency
to write passwords down and the security risks that presents.19
Life of the password
Increased security comes from passwords that are required to be changed on a regular basis, since the
more the password is changed the more the risk of it becoming known is reduced. As a result, some
systems will require users to change their password on a regular basis (e.g. every four weeks). While this
has the benefit of being dynamic because it changes regularly, it can obviously lead to confusion for the
user, with the regularly changing password leading to the user forgetting or confusing their password.
Other factors linked to difficult-to-remember passwords include the composition of the password and the
selection method of the password (did the user choose it or was it assigned to them?).20
Uniqueness of the password
A user may have access to several different systems or modules within a system. If each of these requires a
password, the potential exists for the user to have to remember numerous passwords. Again, this may lead to
confusion for the user in trying to remember their various access codes.21 The temptation for users may be
to use the same password for various systems. For example, you may use the same password for your email,
eBay, Amazon and YouTube accounts. Ives, Walsh and Schneider22 cite research that found that a typical
internet user may have access to as many as 15 different accounts, each requiring a user identification and
password. With so many accounts, it makes sense to use the same password to reduce the potential for a for-
gotten password. However, the risk is that, if your password for one account is discovered, it can obviously be
used to access multiple accounts. As such, the potential consequences of the password breach are magnified.
When a login is unsuccessful
If a user forgets their password they will not be able to access their account. A system should be configured
to log unsuccessful login attempts. Keeping a log of unsuccessful login attempts can be useful for following
up on potential attacks. Analysis may reveal that attempts happen at a particular time or through a particular
user name. This could prompt further investigation. In addition, some systems may freeze an account after a
number of consecutive failed login attempts.23 Typically, after three unsuccessful login attempts, an account
may be frozen. This control works to stop systematic attempts at determining a user’s password. Once an
account is frozen, the fact should be logged and the user required to reset their password.
Security of the password
Given that most system users will have multiple passwords, the tendency is for these to be written down.
From a control perspective, the writing down of passwords should raise questions about where the docu-
ment containing the passwords is then stored.24 For example, storing the passwords in a notebook that is
locked in a desk drawer or filing cabinet is preferable to recording them on a post-it note affixed to the
computer screen where anyone can access them.
Security threats and our responses to those threats are evolving, and security advice can become
obsolete. For example, users of information systems are encouraged to use long, complex passwords.
However, accounts are compromised regularly (see, for example, data breaches discussed later in this
section) through password reuse, which is a bigger threat today than password cracking. Therefore, the
better advice is to use different passwords for different sites rather than creating a complex password,
memorising it and using it for all the systems you use.25
CEB’s 2015 Audit Plan Hot Spots lists information security to be a key area because of insecure
employee behaviours. 26 For example, 93 per cent of employees admitted to violating information security

386 PART 2 Systems characteristics and considerations

policies. Importantly, the report notes that organisations that focus on technical controls at the expense
of proactively managing secure employee behaviours (for example, appropriate password protection)
can lead not only to financial consequences but also to reputational, operational and legal consequences.
Recent research has suggested two ways to deter users (or insiders) from fraudulent behaviour. The
first is to ensure employees understand the risk of detection. Those employees who believe there is a
high chance of being caught will desist from committing a fraudulent act. The second is to create a fair
work environment where employees believe they are treated fairly.27

System development procedures

A number of different information systems can exist in the organisation that will require maintenance and
development at various points in time. It is important to have in place set policies and procedures to be fol-
lowed in the design and implementation of new software or systems. These should include designated pro-
cedures and stages as part of the systems development process as well as restrictions on who is able to initiate
and execute the development and installation of new programs within the information system. Within an
organisational network you will see this represented, at a simple level, by different user privileges granted
across the organisation. For example, the system administrator will have the ability to install software,
whereas a business user will not have such rights. Restricting users’ ability to install and modify software can
be seen as a preventive control since it provides reasonable assurance that untested or incompatible software
and software that has not been appropriately reviewed or licensed will not be placed on the system.

User awareness of risks

Another organisational control strategy is to ensure that management makes their employees aware of
the various information system risks by investing in security education training and awareness (SETA)
programs. This can include briefing sessions about password policies and computer monitoring. Man-
agement should ensure users of organisational information systems are aware of the security threats and
issues, and understand organisational security policies and the policies for detection of fraud.28

Data storage procedures

Information is stored on servers about customers, staff and intellectual property. If a competitor was able
to access this information it could cause serious consequences for the organisation,29 both financially
and non-financially (for example, reputational damage). Increasingly, management in organisations need
to manage the risks associated with data storage either locally on their premises or in a data centre, or in
the cloud. Two major risks are associated with cloud storage. The first is the inability to audit and mon-
itor at file level. The second is the inability to access the internet to access data.30
Being clear on what data is needed by different parts of the organisation, and setting up access rights
accordingly, is also an important control step. In addition, where data is of a sensitive nature, logs
that record when the data is accessed and who accesses the data can be an important resource used by
auditors and investigators.
Another dimension that raises control concerns related to data and technology resources is increased
mobility. IT executives and Chief Information Officers may be reluctant to adopt cloud services, particu-
larly mobile cloud, because of security and privacy concerns. The unresolved security issues relating
to mobile cloud environments include data security, network security, data locality, data integrity,
web application security, data segregation, data access, authentication, authorisation, data confidentiality,
data breach issues, and various other factors.31
Accordingly, control procedures relating to the access, duplication and sending of data are an impor-
tant aspect of general control policies, particularly as more organisations decide to adopt cloud-based
services for storing data. Examples of such control policies include, but are not limited to:
•• restriction of user privileges — who can read data only versus who can also copy data
•• encryption of stored data

CHAPTER 9 Internal controls II 387

•• encryption of data being sent between locations
•• access logs for the access and alteration of data
•• firewalls to protect data and systems from unauthorised external access
•• regular updates of virus definitions
•• regular system scans
•• scanning of attachments before opening/downloading
•• policies on attachments that will be accepted by the email system
•• password/biometric identification in start-up routines for computing devices
•• physical locking of portable computing devices when left unattended.
Backup policies are also important as backups may be the only means of recovery in the event of
destruction or corruption of data. The frequency of backups is an organisational decision, based on the
extent of data and the extent to which data change on a day-to-day basis. However, important aspects to
keep in mind when developing a backup policy are:
•• keeping multiple backups
•• storing backups off site or in the cloud
•• keeping multiple versions of backups
•• deciding what and how frequently to back up.
Several organisations now offer services such as offsite storage and backup facilities, making use of
internet technology as a way of transferring backup data to remote locations and adding that extra degree
of security should something go wrong at a main site.
Scheduling of backups is also of consideration. Traditionally, systems that operated in a batch-­
processing environment would perform scheduled backups in the evening when the system was not
performing routine transactions. Of course, once the first transaction of the new day occurs, the backup
is out of date. In this instance, the backup mitigates the loss but does not eliminate it.
Movement has been made towards real-time backups, whereby as transactions occur data is updated
on site as well as at the backup site. This approach effectively synchronises the business’s main site
with the backup site, with processing occurring at both locations and a backup existing that is as recent
as the last transaction. The potential downside to this approach is that it obviously places a demand on
communication between the two sites and will be more costly to maintain.32

AIS FOCUS 9.2

Privilege vulnerabilities
Data breaches over the last few years have alerted managers and their organisations to the emerging
risks to IT systems. The Target credit card breach and the Sony data breach were two examples of not
only financial vulnerability but how reputational credibility can be tarnished.33 Forbes reported 20 credit
card breaches during 2013/2014, including the Target breach. These breaches occurred at well-known
US companies. With department store, Neiman Marcus, 350 000 customers were affected when mali-
cious software was installed on the systems that collect credit card payments.34 In December 2013,
Target reported that as many as 40 customers who used their credit or debit cards may have been
hacked between 27 November and 15 December of that year.35 In September 2014, Home Depot, the
world’s largest home improvement chain, confirmed that 56 million credit and debit cards were affected
by malicious software installed on the sales terminals.36 In view of all these reported data breaches, and
more being reported in the media every week, it would follow that managers and their organisations
would focus on investing in cybersecurity measures to repel these attacks.
However, writing in The Conversation, Dean argues a different perspective. Governments do not
encourage better cybersecurity. To the contrary, American, United Kingdom and Australian governments
are legislating for more sharing of data with intelligence agencies. Analysing Sony, Target and Home
Depot’s financial statements showed that the breaches did not impact their financial performance. In
fact, the cost to these companies was less than 1 per cent of annual revenues. Basically, the point is
that it does not make economic sense for them to improve their information security.37

388 PART 2 Systems characteristics and considerations

Security policies
Aware of such risks to their information infrastructure, organisations have looked towards policies and
procedures to protect their electronic resources. Information security policies document an organ­isation’s
approach to security, usually by following a framework and/or standard. The policy documents should
be understood and used by everyone who has access to an organisation’s information systems. As an
example, the Australian Government Information Security Manual was developed to be used for the
risk-based application of information security controls.38

9.6 Application controls

LEARNING OBJECTIVE 9.6 Explain and provide examples of application controls.
Application controls are those built around the operation of a particular process and typically relate to
the key system stages of input, processing and output. Accordingly, this section looks at each of these
stages and considers some examples.

Input controls
Standardised forms
The use of standardised forms can help ensure completeness. The design of the form that users interact
with when entering data into a system is also an important consideration. There is benefit in designing
the screen to resemble closely its paper-based equivalent in the real world. This makes it easier for users
to navigate the screen and ensure completeness in their input. Proper form design can also ensure accu-
racy, since the form will specify the data that is required, the expected length of the data (e.g. six boxes
for a six-digit customer ID) and any specific instructions for the data provider. Standardised forms can
be seen as a preventive control (they work towards ensuring all relevant data is provided by specifying
what must be completed, reducing the chance of incomplete forms) and a detective control (a visual
inspection of a completed form will quickly detect if any key components have not been filled in or have
been filled in inaccurately).
Prenumbering documents
Prenumbering important documents, such as invoices, purchase orders and cheques, can be a simple
but effective way of helping ensure the objective of completeness. When documents are prenumbered,
any missing or unaccounted for documents can easily be identified simply by looking for a gap in the
sequence. For example, an organisation may prenumber its purchase order forms. If an examination
of the purchase records shows that issued purchase orders on record go from form number 10 011 to
10 013, with no record of 10 012, then potentially a purchase order has gone missing. This missing
document could be explained by honest misplacement, fraudulent use by an employee or simple can-
cellation. However, if documents were not prenumbered, this missing document would never have been
identified. By prenumbering the source documents, a control is built that helps identify any omitted
or unrecorded transactions (the assertion of completeness) and also provides a control over the source
documents.
Where the source documents are potentially valuable, for example cheques, it is also useful to keep a
record of cancelled source documents. Cancelled source documents are those that are removed from cir-
culation by the organisation. For example, document number 10 012, which may have been previously
identified as missing, could have been cancelled by the organisation because of an error while filling
out the form or cancellation of the order before sending the purchase order. If a record is maintained of
cancelled source documents, then reconciling gaps in the sequence of source documents also becomes
easier.
Prenumbering documents can also be a useful control to address concern about transactions being
classified in the correct reporting period. As an organisation approaches the end of the financial year

CHAPTER 9 Internal controls II 389

it can note the last number of key source documents, for example, sales invoices, and set up pro-
cedures to make sure that documents after that number are allocated to the next period. The use of
prenumbering and classification filters and ranges within accounting software can work towards this
goal. For example, if we know that the first source document issued in the period was number 299
and that the last one issued at the end of the period was 542 then, combining knowledge of these
numbers with the beginning and end dates for the financial period, we can filter and sort the docu-
ments to check that all documents before 299 have been recorded in the previous period and all docu-
ments after 542 have been recorded in subsequent periods. The ability to filter transactions in this
way is present within various accounting packages, as well as through the downloading of data into a
spreadsheet and manually sorting the data.
Sequence checks
In a computer-based information system, prenumbering can be further enforced through the use of
sequence checks. If transactions are entered directly into the system, with no paper documentation, then
the document number can be assigned automatically. This will ensure no missing numbers in sequence
checks for transactions and reduces the risk of incomplete data (i.e. transactions not being entered). It
could also be argued that sequence checks contribute towards ensuring the correct valuation of assets
since, for example, if a sale is not recorded, the associated increase in accounts receivable will not be
recorded.
Turnaround documents
Turnaround documents are documents that originate as the output of one system and become the
input for another system. There are literally hundreds of examples of turnaround documents that you
would have been exposed to. If you have ever flown with a major airline you will have unwittingly
been exposed to turnaround documents. Think about what happens when you travel by air. You arrive
at the airport and check your baggage in at the baggage counter. While there you will also present
the relevant identification, including a passport if travelling overseas. The attendant will check your
baggage in and allocate you to a seat, and then issue you with a boarding pass. The boarding pass
contains details of your flight, departure gate, boarding time, seat allocation and any other relevant
details. When you then proceed to the boarding gate you present your boarding pass, which is scanned
through a machine. What is the benefit of using this document at the boarding point? Airlines need
to keep lists of who actually boards aircraft, because an aircraft will not take off if a passenger has
checked in luggage but not boarded the flight. This presents the issue of how to best capture the data
about which passengers have boarded the flight. One option could be to have boarding staff rekey
data into the system as passengers present their boarding pass. However, this is not the most efficient
way — the data have already been captured elsewhere, so why rekey them? Instead, the airline mag-
netises boarding passes that it issues, enabling a computer to read the data that were stored when the
passenger checked in. This has several benefits. The obvious benefit is that staff members do not have
to rekey passenger data, meaning that boarding can be completed in less time. Second, the risk of
error is reduced since there is no opportunity for human error when rekeying the data. The data are
accessed electronically from the boarding pass, so the risk of inconsistent data (mismatches between
what was captured when the passenger checked in and when the passenger boards the plane) are
reduced. This increases the chances of input validity.
The boarding pass is a specific example of a turnaround document. Another example of a turnaround
document is a remittance advice. When you receive a bill or a credit card statement you will often
notice that it has a detachable slip attached at the bottom. This slip is designed to be returned to the
organisation that originally sent you the bill, accompanied by the payment. Take a closer look at the
remittance slip and you will notice that a lot of the data are already filled in, for example, customer
number, amount owed and due date. Why prepare remittance slips? When returned with the payment to
the organisation, these slips allow payments to be linked to customers, so the organisation knows which
customer the cash receipts come from. Additionally, the details of the cash receipt are on the remittance

390 PART 2 Systems characteristics and considerations

slip and just have to be entered by the relevant person. The benefit is that there is no reliance on the cus-
tomer to fill in the slip, reducing the possibility of errors and helping ensure valid and complete inputs
are entering the system.
Use of turnaround documents helps achieve completeness of data entry, with all required data con-
tained in the turnaround document. Turnaround documents that contain values or monetary amounts also
help contribute towards the correct valuation and measurement of transactions (assertion of accuracy).
Data entry routines
A computerised information system can also have built-in programs that ensure inputs are valid and in
the correct format. Examples of such routines are field checks, validity checks, completeness checks,
limit checks, range checks, reasonableness checks and redundant data checks.
Validity checks take a given input for a field and ensure that it is an acceptable value. For example, if
a customer number is being entered when recording a sale, the program may take the customer number
that is input and check it against a master list of customers contained in the customer table of the data-
base. If the customer number appears on the master list then the input is valid and the input stage can
proceed. However, if the customer number does not appear on the list then an invalid customer number
has been entered. Obviously, this is not acceptable, so the system will alert the user to this error and
refuse the input. This removes the potential for invalid or nonexistent customer numbers entering the
system, helping attain existence and occurrence. KPMG’s Fraud, Bribery and Corruption Survey 2012:
Australia and New Zealand found that false invoicing was the main fraud category for management,39
making the issue of being able to validate transactions an important one for organisations. In a rela-
tional database environment, a control of this nature can be established using primary and foreign keys
and through the enforcement of referential integrity. This is discussed in chapters 3 and 4 on data-
bases. Validity checks can contribute towards data accuracy (e.g. does the customer exist in our customer
table?), ensuring data are entered correctly.
An example of how a validity check may appear in a systems flowchart (which shows the internal
entities and the activities that they perform) is shown in figure 9.1. In this example, the customer number
is being entered and the customer details are then being retrieved and displayed on the screen for the
next stage in the process. Notice that this control requires access to the customer data in order to confirm
that the customer exists on the customer list.

Data entry person Computer

Start

Customer
data

Customer
order

Check
Customer customer
number on list

Customer
number

FIGURE 9.1 Checking customer exists in customer table

CHAPTER 9 Internal controls II 391

 An example of a validity check in QuickBooks, one of the popular computerised accounting packages
in use in Australia, occurs when entering journal entries. If you try to enter a journal entry with debits
and credits that don’t balance, an error message will appear alerting you that the entry is invalid since
the debits and credits do not equal.
Completeness checks ensure that all required data are entered. If a user is entering a sale into the
sales system and the sales screen has ten different fields to be completed, then it needs to be ensured
that the user completes all ten fields. Failure to do so will lead to incomplete data about the transactions
being entered. A completeness check will ensure that all required data are entered before the user can
advance to later screens or move to a new sale. A practical example of such a check can be found in a
lot of website store fronts and web-based forms. If you have ever completed an online form or made
an online purchase, you will have probably noticed that some of the fields are marked to designate
them as required fields. If you try to proceed without putting data into the required fields, the site will
return an error message and not allow you to go any further until the required fields are completed.
This is a way of trying to enforce input completeness for online forms and will contribute to the goal
of completeness. Again, this control can contribute to the accuracy of the data that has been recorded;
if necessary data about a transaction is not recorded then the details about the transaction cannot be
deemed to be accurate.
Limit checks will check values input into a field to make sure they fit within a predetermined upper
limit. For example, there may be a firm policy that orders must be a maximum of 50 reams of paper
at any one time. A limit check will detect any amount greater than 50 entered in the quantity field and
reject it. The application of limit checks is a technique for attaining the correct valuation or measurement
of transactions.
Range checks function in a manner similar to limit checks, with the exception that the checks apply
to both upper and lower limits. Returning to the paper ordering example, if store policy is that anywhere
between 30 and 50 reams of paper can be ordered at one time, then the range check will detect any
amount outside these upper and lower limits. Similarly to limit checks, range checks help reasonably
assure the correct valuation or measurement of transactions.
Reasonableness checks operate to check that the numeric input for a field is within a
reasonable numeric range. For example, if a field requires you to enter your number of hours
worked for a week and you key in 400 instead of 40, a reasonableness check should identify this
value as outside reasonable values for weekly hours and prompt you to correct the value. Once
again, this check will contribute towards the aims that relate to the valuation and measurement of
transactions.
If data are being entered for a critical event or important transaction, then a control that can be used
to help ensure correctness of inputs is a redundant data check. This control operates by having the data
entered twice and then checking the two sets of inputs and making sure that they are identical. Ideally,
different people will perform the two inputs, making the system’s comparison of inputs more mean-
ingful. Obviously, this control has the disadvantage of being costly to implement, since data are required
to be entered twice. Accordingly, a key factor in determining whether to implement this control will be
the cost–benefit principle. If the cost of having the data entered twice exceeds the benefits, then this con-
trol would not be applied.

Automated form completion

A step forward from the validity checks mentioned above is to automate part of the data entry
routine. For example, when entering customer details to record a sale, once the customer number
is entered the computer can automatically fill in other customer-related data fields (customer name,
address, phone number and so on). This is done by looking up the customer number in the cus-
tomer data table and retrieving all related data. The benefit of this control is that it makes data entry
more efficient, since less time is spent keying in details. In addition, by reducing the amount of data

392 PART 2 Systems characteristics and considerations

entry the chances of data entry errors are reduced (i.e. as long as the customer number is correct all
related data items will be correct). Of course, this assumes that the customer details in the database
are up to date.
The input controls mentioned above aim to provide reasonable assurance about the accuracy and val-
idity of data that is entered into the system. Data entry errors that make it through the input stage can
have costly consequences. AIS Focus 9.3 demonstrates the implications of using spreadsheets that have
limited controls.

AIS FOCUS 9.3

Human error: the biggest problem

Organisations increasingly rely on technology to automate and streamline business processes. How-
ever, the potential for human error is increasing. Bloomberg reports that, in 2013, organisations in the
United States accumulated US$7 billion in penalties to the Internal Revenue Service for incorrectly
reporting business income and employee values. The Bloomberg survey found that new technology
and human error had led to incorrect data being input into enterprise systems for over a quarter
of respondents (27.5 per cent). A second prevalent error was deleting formulas from spreadsheets
(17 per cent). A third error was overriding system data with numbers outside the enterprise system
(13 per cent).40
Research shows that up to 88 per cent of spreadsheets have errors.41 Spreadsheet errors are
both costly financially and damaging to an organisation’s reputation. F1F9, a financial modelling
business in the United Kingdom, compiled an eBook on the top 12 spreadsheet disasters.42 Many
of these stories were provided by the European Spreadsheet Risks Interest Group (www.eusprig
.org/horror-stories.htm). One of the biggest mistakes was made by two Harvard professors:
Carmen Reinhart and Kenneth Rogoff. Their research relied on a spreadsheet to calculate govern-
ment debt to GDP ratios. When this spreadsheet was examined by doctoral student Thomas
Herndon and Professors Michael Ash and Robert Pollin at the Political Economy Research Insti-
tute at the University of Massachusetts Amherst, they found three major errors in the spread-
sheet. The flawed statistics had been quoted as a basis for a number of European government
austerity measures, which had a profound impact on millions of citizens. That is, the conclusion
of an important ground-breaking paper — which had been widely quoted in political debates in
North America, Europe, Australia and elsewhere — was invalid because of spreadsheet errors.43 It is
important to remember that the errors reported were only those that are in the public domain. How
many errors and how much damage to an organisation’s bottom line and reputation are difficult to
calculate.

Transaction authorisation procedures

Obviously, an organisation does not want all types of users to enter all types of transactions into the
system. For example, it is probably not wanted that a member of the sales staff should handle payroll
transactions and someone from manufacturing should enter sales transactions. One way this can be con-
trolled is through the correct setting of user privileges when the system is established. For example, by
requiring staff to log on with unique user names and passwords, user privileges and access rights can
be established that restrict the functions they are able to perform in the system. This control can help to
prevent unauthorised transactions entering the system. Risks presented by unauthorised transactions can
be quite large, for example, the National Australia Bank announced a loss of $360 million as a result
of unauthorised foreign currency transactions executed by staff.44 The issue of authorisation and access
rights has become important for organisations with the increased emergence of ERP systems. Because
of the integrated nature of an ERP system, along with the ‘interconnectivity and automation of pro-
cesses’,45 correctly authorising employees’ access and privileges is an ongoing, time-consuming and
complex process.

CHAPTER 9 Internal controls II 393

 Authorisation procedures can also help in the attainment of the objectives of existence and
occurrence, particularly if a separate person provides the authorisation. They can also include the
review of event data before the execution of the event. An example of this could be seeking man-
agement approval for an abnormally large sales request from a customer, where the customer is
new or unknown or where the transaction is outside the amount the staff member is authorised to
execute. A frequent example of the authorisation control in action is in retail transactions. Often
there will be a negotiation over the sales price, with the sales attendant being asked about discounts
on the marked price for an item. When entering the negotiated price into the system, management
authorisation would typically be required to confirm that the discount given was appropriate and
approved.

Batch totals
Batch totals are another effective input control. In a batch environment, transactions are accumulated
and, at some set interval, processed. In a sales system, for example, invoices may be accumulated until
the end of the day and then processed upon the completion of the day’s trading hours. A concern in
this environment is making sure that all of the invoices are recorded in the system at the end of the day
(completeness). This can be helped by the use of batch totals. For example, the sales staff may accumu-
late their invoices and at the end of the day count how many invoices they have. This batch of invoices,
together with a batch header form detailing who prepared the batch and the number of documents in the
batch, could then be sent to the data entry staff, where they would be entered in the system. Staff in data
entry should check to ensure that they received the number of documents indicated in the batch header
form, and that all these documents were entered. This is an example of a document count batch total. It
operates to make sure no documents are missing, but it has limitations. While the data entry staff may
enter all the invoices, they may key in details different from those on the invoices, for example, they may
key in sales of $100 instead of $1000. This will not be detected by the batch totals based on the number
of documents.
An alternative method to help with both completeness and valuation or measurement could be to use
total sales dollars for all invoices in the batch. The batch process would operate as described above, but
instead would be calculated based on the sales value of the invoices. This overcomes the limitation of the
document count approach.
If the batch total is not meaningful in any way, and just a check device, meaningless items can also be
used (e.g. the total of all customer numbers in a batch). These sorts of hash totals are typically used as a
processing control, and are discussed in the next section.
An example of a batch total is shown in the systems flowchart in figure 9.2. In this example a batch of
sales invoices has been gathered and a batch total manually calculated. The invoices are then entered into
the computer, which displays a batch total on the screen. The total is compared to the manually prepared
total. If the two totals agree then, as a minimum, we can be confident that all invoices have been entered
into the system.

Independent reviews
An independent review is a useful monitoring technique that involves the work of one person
being reviewed by a different person to ensure completeness, accuracy and correctness, and can
potentially make information more valuable. If the same person performs the work and checks the
work for errors, the review is of little value. Consider if students were able to mark their own exam
papers — there would be a chance that errors would not be detected or that proper marking pro-
cedures would not be followed. For example, data about banking transactions may be processed into
a bank reconciliation report for review by an independent person, who then compares it against cash
receipts and payments listings and bank statements to verify the reliability of the bank reconciliation
process.

394 PART 2 Systems characteristics and considerations

 Data entry person Computer

Start

Invoice

Calculate
batch total

BT

Invoice

Calculate
Invoice data
batch total

BT

Batch total
Invoice

Compare
totals

BT

Invoice

FIGURE 9.2 Reconciling batch totals

Processing controls
Processing controls aim to ensure that data within the system is correctly and accurately processed. An
example is sales data entered throughout the day being transferred to accounts receivable to update the account
balances. Controls relate to how the computer handles the data in transferring it from one file to another, and
assurance is needed that (1) all sales have been transferred to accounts receivable and (2) all sales have been
correctly transferred to accounts receivable. This example is illustrated in the following discussion.

Run-to-run totals
In a computer processing environment, data will be gathered, used in a process and stored at a destination.
The idea is that the total of the data before the process of updating the data files should match the total
of the data after the update has been performed. If we think of the sales/accounts receivable discussed in

CHAPTER 9 Internal controls II 395

the batch total example, the closing balance of accounts receivable (after the sales have been transferred)
should equal the opening balance (before transfers) plus sales (ignoring any payments from customers).
With this logical relationship between the opening and closing data we are able to build in checks to
ensure that updates have been correctly performed. If, after the computer performs the update, the closing
accounts receivable balance is less than the check total we calculated prior to the update (opening balance
plus sales), the possibility exists that (1) not all sales have been transferred to accounts receivable or (2) all
sales have been transferred but they have been transferred at the wrong amount or to the wrong account.
Figure 9.3 illustrates this process. As sales orders are entered into the system they are added to the opening
accounts receivable balance to determine the correct balance after the data update has taken place. The
accounts receivable file is then updated with the details of the sales and a closing balance is calculated.
This closing balance is compared to the one calculated in the data processing activity. If the two totals (pre-
and post-processing) agree, the data has been correctly transferred to the accounts receivable file.

Salesperson Computer

Sales order Capture sales

Calculate
check total
Order details A/R
Credit
sales
Update accounts
receivable

Compare
totals

FIGURE 9.3 Run-to-run totals

An alternative conceptualisation is to think of a typical manual accounting system.

1. Enter transactions into journal.
2. At the end of the reporting period the journals will be posted to the ledger accounts.
3. Take a total of the debits and credits before posting the amounts.
4. Post amounts to the ledger accounts.
5. Compare the change in the totals for debits and credits on the trial balance with the total of the debits
and credits for the journal entries. These two amounts should be identical since all that has been done
is to add the journal entries to the ledger accounts.
6. If these amounts are different, a problem or error has occurred during data processing.
Run-to-run totals aim to check that processing of data has taken place correctly, no errors have been
introduced and no data has been lost. Notice how this control does not prevent the error from happening.
Rather, it detects that there has been an error in processing and alerts the user to the problem.
Run-to-run totals will typically relate to the accurate processing and updating of data and, as such,
can apply to the correct valuation of accounts (e.g. accounts receivable), accuracy of items (have the

396 PART 2 Systems characteristics and considerations

amounts been correctly recorded?) and completeness of transactions (have all transactions affecting an
account been included?). For example, if there are ten sales and only nine are transferred to accounts
receivable this will be detected by the run-to-run total.
Other examples of detective controls include performing reconciliations, the use of batch totals and
independent reviews of people’s work.
Reconciliations
You will recall from introductory financial accounting units that the purpose of a bank reconciliation is
to check business records against those of the bank, enabling any inconsistencies between the two to be
identified. This reconciliation process is a valuable part of an organisation’s internal control activities,
providing it with a way to protect its cash resources. Another example is reconciliations of control and
subsidiary ledger accounts. Reconciliations allow the comparison of two sets of information that should
theoretically be the same to identify any inconsistencies. Reconciliations are more powerful if the two sets
of information are prepared by two different people and an independent third person performs the review.
For example, the accounts receivable control account may be maintained by the general ledger division,
the subsidiary ledger by the accounts receivable department, and the reconciliation of the two may be per-
formed by the finance manager. There is little value in reconciling two sets of information prepared by the
same person — as the person preparing the information has the opportunity to cover up any discrepancies.
Batch totals
Batch totals, as explained previously, can also be used as a control for data processing, since if data is
being shifted from one file to another the data should not change. As such, the total of the data (be it
number of records or dollar values) should be the same before and after the processing occurs.
Sequence checks
Sequence checks, as discussed previously, can also be used during the processing of data. At the pro-
cessing stage, these checks can operate to ensure that no data have gone missing during processing
activities. An example could be in the transferral of cheque payments from the cash payments journal to
the ledger accounts. If, in the journal, we are able to identify a sequence of cheques numbered 1 through
to 5 but the ledger contains cheques 1, 2, 3 and 5, the gap in the sequence tells us that somewhere in
processing the cheque data an entry has been lost.
Run-to-run totals
Run-to-run totals will help identify whether any transaction data have gone missing between when they
were first gathered and after their processing, while accuracy is attained by checking totals to ensure that
they are the same before and after the processing of data.
Hash totals
Hash totals are batch totals based around meaningless figures, for example, the sum of all customer
numbers in a batch. Use of hash totals can help to detect any errors that may have entered the data
during processing (e.g. if a hash total is taken before and after processing), as well as attain complete-
ness in updates and processing.

Output controls
Output controls are built around protecting the outputs of the system. These controls protect access to
outputs as well as the format and content of outputs. Examples of output controls include access privi-
leges and the ability to generate reports, page numbering of reports and end-of-report footers.
Within any information system there will generally be users with different responsibilities and duties. For
the principle of segregation of duties to operate effectively, these different users should have their access
privileges clearly defined based on the requirements of their job, which will be contained in their job descrip-
tions. As an example, for reasons of confidentiality it is not desirable for all employees to be able to access
payroll data and reports on annual salary levels and bonuses. Only those in the human resources department

CHAPTER 9 Internal controls II 397

should be able to access such details. Alternatively, the salesperson should not be able to update inventory
records and the inventory manager should not be able to modify or create sales records. These concerns can
be overcome by correctly establishing user privileges that relate to the data the user can add, delete or modify,
as well as the reports, queries, outputs and information the user can access. In the integrated environment of
an ERP system, the correct definition of user access privileges is especially important.46
Another concern about outputs, apart from who can access them, includes the physical control over
them once they are generated. Confidential or privileged information should not be printed on a printer
accessible by all staff; such output should be printed to a secure location where only those authorised to
access the information have access to the site. For example, employee appraisal forms would probably
be best printed to a secure printer in the HR manager’s office rather than to a general printer that all staff
access for their print needs. Once reports or information have been generated, it needs to be ensured that
there is an entire set of information. So for a multipage output that is printed, a simple but extremely
effective control to ensure completeness of the output received is to preformat footers to provide page
numbering, for example, ‘Page # of ##’. With this page numbering system, pages collected can be iden-
tified as well as the number that there should be in total. So if there are six pages and the footer says
there should be seven, it is easy to see that this is not the complete report. Along similar lines, prefor-
matting reports to contain a simple message such as ‘END OF REPORT’ at the completion of the report
is another way to ensure that you have the final page. This, combined with page numbering, can be an
effective way of ensuring that any missing pages of output are quickly identified.
Database queries
Database queries can also be a powerful tool for detecting irregularities or anomalies.47 For example, if
a company suspects that an employee is posing as a vendor, submitting fake invoices and receiving pay-
ment for these invoices, a quick crosscheck of employee addresses and vendor addresses could detect
this. Alternatively, if it is suspected that accounts staff are keeping cash paid by accounts receivable
customers and reducing accounts receivable through a sales return or credit note entry, a query of sales
returns by customers and sales staff could be useful to detect irregular levels of returns, which could then
prompt further investigation.

AIS FOCUS 9.4

Controls in practice
As the internet has increased its presence over the past decade, several organisations have been con-
fronted with control issues that were previously unheard of in the business environment. One area where
there are numerous examples of this is in the use of credit cards for online transactions. A growing con-
cern for organisations is the use of credit cards for online gambling.
In the United States there is increasing concern about the legality of internet gambling, with it being
legal in some states and not in others. In addition to the issue of legality, some major credit card pro-
viders are now refusing to process transactions that are related to internet gambling. VISA, MasterCard
and American Express are examples of major credit providers forbidding the use of their credit lines for
internet gambling.
This means that, while the online casino provider may accept a customer’s credit details, process
the transaction and provide the customer with money for online gambling, when it comes to collecting
that money from the credit card company or bank, the online casinos are being met with refusals. Court
judgements in some US states have ruled that gambling debts accrued on credit are not enforceable.
This has raised a new issue for credit card providers, with some offshore credit processors potentially
being willing to process the transactions for the online casinos but using fake codes, so that they do
not appear as gambling-related items when the credit card company receives the transaction details.
Given this scenario, and the possibility of faking transactions to disguise gambling-related debts,
what internal controls could the credit card companies implement to prevent, detect and correct the use
of fake transaction details?48

398 PART 2 Systems characteristics and considerations

9.7 Disaster recovery plans
LEARNING OBJECTIVE 9.7 Evaluate the operation and components of a disaster recovery plan.
Another crucial aspect of an organisation’s control system is its ability to recover from any accidents or
disasters that may occur and to minimise the damage to the organisation and its resources. This aspect of
the control system is encompassed in the disaster recovery plan, which is the strategy that the organ-
isation will put into action in the event of a disaster that disrupts normal operations in order to resume
operations as soon as possible and recover data that relate to its processes.
The obvious example of a disaster is the terrorist attacks of 11 September 2001 against the World
Trade Center in New York. As the Twin Towers collapsed, businesses were suddenly confronted with
the prospect of immense losses, both in terms of assets and knowledge lost and downtime in operations.
PricewaterhouseCoopers estimates that ‘14 600 businesses in and around the World Trade Center were
impacted by the disaster’ and that ‘652 companies were temporarily or permanently displaced by the
destruction’.49 Even for organisations not directly affected by the collapse of the Twin Towers, there
was still the problem of power outages and disrupted utility services to deal with in trying to keep their
operations running.
It can be argued that most Australian businesses are inadequately prepared for any form of major dis-
aster.50 Internationally, the trend appears to be the same, with AT&T finding that 25 per cent of large
companies (those with more than 100 employees) do not have disaster recovery plans.51 As organisations
increasingly place their operations online, the pressure to keep the web interface continuously operating
escalates. For an online company, the web server going down or the IT infrastructure failing effectively
closes the shop. A closed shop means no revenue. Over an extended period of time this can spell disaster
for an organisation.
As a result of the threats of disaster — whether they be a result of terrorism, or natural disasters such
as fire, floods, cyclones or earthquakes — organisations must consider how they can deal with such
threats. Their reaction to the threat of disaster can be preventive or corrective. The main aim for an
organisation in the event of a disaster that disrupts business operations is to limit the time the business
is out of operation and minimise the extent of loss to existing business resources — particularly infor-
mation — so that the business can recommence operating as quickly as possible. The way an organ-
isation does this is outlined in the disaster recovery plan, which will include provisions for temporary
sites, the restoration of business networks, staffing and preserving business relationships.

Temporary sites
In the event of a business’s place of operation being destroyed it needs to be able to resume oper-
ation in a new location as soon as possible. This is the role of the temporary site, and for a business
there are several approaches to choose from, including the establishment of hot sites, cold sites and
autonomic infrastructure. An organisation that can ill afford downtime due to disaster may consider
the establishment of a hot site. This is a separate facility located away from the organisation’s usual
premises and contains offices and the necessary equipment (such as IT, telecommunications and data)
to get the business back up and running in the minimal amount of time after a disaster occurs. Essen-
tially, it is a standby site ready to be called into immediate action should the organisation require it.
Many different hot-site subscription services are available, with organisations able to sign up with,
for example, HP, which has 44 such sites around the world for lease, or IBM, for the provision of a
hot site.52
An alternative to the hot site is a cold site. Unlike a hot site, a cold site does not have the necessary
equipment and data in place for the organisation to immediately continue operations. Rather, it is an
available office with basic telephone and electricity supplies ready for use should they be required. How-
ever, the organisation using the cold site still has to arrange for the necessary data, technology and other
resources that are required to resume business operations.

CHAPTER 9 Internal controls II 399

Staffing
Staffing issues in the event of a disaster can be divided into two categories: the evacuation of staff who
are present at the location of the disaster, and access to staff after the disaster. In the event of a dis-
aster, obviously staff need to be familiar with the appropriate evacuation procedures. After a disaster,
organisations need to be able to contact key employees who are part of the recovery plan to ensure
that the disruption to the business is minimal. Accordingly, plans should be set out for how key staff
members such as the CEO and division managers can be contacted. After all, even the best planned dis-
aster recovery procedure is useless if nobody is present to implement it.
If the recovery plan requires the action of staff, it is critical to ensure that they know what their
role is and how they fit in to the overall plan. This is why regular drills to ‘practise’ the recovery plan
are important. Additionally, if part of the plan involves switching to a remote site in another city, town,
state or country, the organisation should ensure that the people who are to operate that remote site are
aware of what they are required to do and ready to put the plan into action at a moment’s notice. There is
little point having a fully equipped hot site ready to run in the event of a disaster and not having people
who can staff the site and keep it going.
Staff responsibilities and roles in the disaster recovery process should be clearly documented, as
should lines of responsibility and reporting relationships.

Restore business relationships

The reality for a business operating in today’s environment is that it will typically be involved in networks
or arrangements with other organisations or individuals. Such networks or arrangements may include
extranets that link the organisation to its customers and suppliers, as well as other arrangements or deals
that may be in place with external organisations. This scenario makes it essential that the organisation con-
sult with such partners and related bodies when developing a disaster recovery plan.53 It is easy just to
think in terms of the business that you are involved in when designing a recovery plan, but the relationships
this business has with other parties will also be affected and, to keep the business’s operations running, it
may be essential to plan to keep these relationships operating in the event of a disaster.
However, merely having a hot or cold site in place should disaster strike is not enough. Once organ-
isations have considered their needs and developed suitable arrangements for a disaster recovery plan, they
should then ensure that the plan can be put into operation. Much as you used to have fire drills when you
were a student at school, an organisation should conduct disaster recovery drills. These involve a mock
execution of the disaster recovery plan to ensure that those responsible can perform their required tasks and
that the plan actually works. Just as dangerous as not having a disaster recovery plan is the organisation
having a plan but not testing that it actually works. Of the 83 per cent of Australian companies that report
having a disaster recovery plan, about 50 per cent had never tested it.54 In the United States, 19 per cent
of companies with more than 100 employees that were surveyed by AT&T had not tested their disaster
recovery plan in the past five years.55 The risk in this case is that, if something goes wrong, staff will not
know how to react, since they have never experienced a drill of the plan. Alternatively, an untested plan
will very quickly become out of date or fail to take into account changes in the organisation or technology.

9.8 Execution of internal control

LEARNING OBJECTIVE 9.8 Critique the execution of control activities.
The execution of tests of internal controls and the evaluation of results are also important activities.56 From
the preceding discussion you should have the idea that control activities can be performed manually (e.g. a
person reconciling the bank statement to cash records or signing off for a transaction to occur) or through the
computer (e.g. edit checks when entering data or run-to-run totals when processing data). The consideration
of control execution — be it manual or computerised — is important, since there are different characteristics
of manual and computerised controls that can impact on their effectiveness within the organisation.

400 PART 2 Systems characteristics and considerations

 Manual controls, by definition, are performed by people. The main disadvantage is that they are
prone to human error and inconsistent application. For example, if a control is that transactions must be
approved by a manager before they can occur, there is the risk that the manager may be inconsistent in
granting approval, be it because of fatigue, human error or favouring certain customers. However, a bene-
­fit of manual controls is that they offer the ability to handle one-off, irregular or infrequent events that
cannot necessarily be prescribed by an algorithm that forms the basis of computer programs. For less
frequent or irregular transactions manual controls may be the more suitable option.
In comparison, computer-based controls offer the benefits of consistent application, timely execu-
tion and a greater degree of difficulty in working around or avoiding the control. Controls that are pro-
grammed into the computer and are exercised by the computer will provide an assurance of consistent
application — the computer follows the same steps and rules each time the control needs to be applied.
In addition, controls that require any degree of computation are best performed by computers because
of their relative efficiency and accuracy in executing calculations. In addition, the data that can be gath-
ered by the computer in executing control activities can provide for further analysis and follow up by
the organisation if required. Computer-based controls are also more difficult to work around. The most
obvious way of avoiding computer-based controls is to manipulate the programmed instructions that the
computer follows; however, few people in an organisation would possess the necessary knowledge to do
this. Computer-based controls, however, are extremely dependent on a sound control environment and
general controls. For example, if general controls are soundly structured (e.g. the separation of duties
within the IT environment, particularly systems development and programming from users), the prob-
ability of program manipulation and alteration is reduced. However, if separation is not present there
is the risk of program and data manipulation by staff in the operation of the computer systems. As a
consequence, when designing computer-based controls it is necessary to consider how well the general
controls are applied throughout the organisation.

9.9 Documenting controls

LEARNING OBJECTIVE 9.9 Demonstrate the different techniques for documenting a control system.
Once a set of controls is established within an organisation, there is a need to document how these con-
trols operate. Remember the emphasis in chapter 7 on the importance of systems documentation for cre-
ating a record of a system’s operation? It is the same principle for internal control systems. Additionally, the
Sarbanes–Oxley Act that was introduced in the United States has made it mandatory for documentation of
internal controls to be prepared by the organisation and audited by the external auditor. There are several ways
that an internal control system can be documented. At an overall level there is the control matrix, which tells us
the control objectives of a control system, how they would ideally be attained, and whether they actually exist
within a system. Australian Auditing Standards provide guidance on some of the forms of documentation that
may be used to document internal control systems within an organisation, with suggestions including narrative
descriptions, questionnaires, checklists and flowcharts. Research by Bierstaker57 found that auditors typically
use narratives to document a system, followed by questionnaires, flowcharts and then internal control mat-
rices. A follow-up study by Bierstaker and Wright in 2004, following legislative changes and auditing stan-
dard changes in the United States, supported this result but found that questionnaires, flowcharts and matrices
had declined in popularity.58 Combinations of questionnaires and narratives, and questionnaires, flowcharts
and narratives were found to be popular. Deloitte & Touche LLP59 also suggests a flowchart-style approach to
documenting internal controls at the individual risk level. This approach will be discussed shortly.

Narrative descriptions
A narrative description of internal controls is probably the simplest method for documenting internal
controls. This approach involves a written description of the system’s operation and how the controls are
carried out within the system. Typically, when carrying out an evaluation of an organisation’s internal
controls, auditors will use the narrative in conjunction with an additional documentation technique, such

CHAPTER 9 Internal controls II 401

as flowcharts or checklists. The benefit of this approach is the flexibility available to the preparer of the
documentation; however, this comes at the cost of structure and consistency in format.60

Questionnaires and checklists

Questionnaires and checklists are another common and easy-to-use approach for documenting an organ-
isation’s internal control system. Figure 9.4 contains an example of a checklist, based on one devised
by Ernst & Young LLP.61 The first column contains a list of the controls one would expect to see in the
nominated environment — in this case the information systems environment. These controls would have
been identified from a list of commonly used controls or, alternatively, arrived at after viewing the list of
threats that was developed during the stage of risk assessment, which was discussed earlier. The second
and third columns allow for an indication to be made as to whether the listed controls exist within
the system of interest, while the final column allows for comments to be made about the control, for
example, why it is missing or how well it operates or any defects in its implementation that are observed.

Control checklist area: information systems

Control Yes No Comment
Are access security software and operating systems
software used to control access to:
• data
• functions of programs?
Is physical security over the IT assets reasonable given the
nature of the business?
Are critical computer data backed up daily?
Is the backup of critical computer data stored off-site?
Are there controls over employees’ remote access to the
system?
Is there a monitoring of IT processing activities by
designated staff, who periodically report to higher
management on IT security?
Is there a log for security violations?
Is the log of security breaches periodically reviewed and
acted upon?
Is IT security periodically audited?
Is there protection to prevent the unwanted corruption and
destruction of and unauthorised access to data records?
Is data processing’s access to non-data-processing assets
restricted (e.g. blank cheques that are used in cheque runs)?

FIGURE 9.4 A general control checklist for the information systems function

The checklist approach for documenting controls would be expected to take place periodically within
the organisation, with a staff member — typically a member of the internal audit division — walking
through the organisation and examining what controls are present or absent. A checklist approach is also
commonly employed by external auditors when evaluating the adequacy of internal controls for an infor-
mation system before the completion of a financial statement audit. The benefit of this approach is that
it is a highly structured means of documenting controls; however, the disadvantage is that it can lead to
a one-size-fits-all approach to documentation as well as to the possibility that controls not listed on the
checklist but in place within the organisation may go undocumented.62

402 PART 2 Systems characteristics and considerations

Flowcharts
Systems flowcharts, as introduced in chapter 7, illustrate a system and its inputs, processes and outputs.
This includes the documents that are part of the system, the processes involved in the system, and the
entities involved in the system. The benefit of the systems flowchart as a source of control documen-
tation is that it contains these different aspects about a system. Because of the detail in the diagram, who
does what tasks can be identified, allowing assessment to be made as to whether separation of duties
has been adequately used. It is also possible to see the activities that occur, allowing the identification of
controls operating within the system. Additionally, by analysing a systems flowchart, any control weak-
nesses that may exist can be identified.
The systems flowchart provides an overall view of the operation of a system, for example, the credit
sales system. However, it provides only a general view of where controls are in operation and little detail
about the actual operation of such controls. Complementing the systems flowchart is a control flowchart.
The control flowchart is suggested by Deloitte & Touche LLP as a way of documenting the operation
of individual internal controls.63 Deloitte & Touche LLP also suggests that any good documentation of
internal control should identify seven key aspects: (1) the risk that the control is addressing, (2) how the
control addresses the risk, (3) details of monitoring for the control’s effectiveness, (4) how the perfor-
mance of the control is assessed, (5) any problems identified in the operation of the control, (6) improve-
ments for the control’s effectiveness and (7) a sign-off date from the control’s evaluation.64 An example
of this approach is shown in figure 9.5.65

RISK: Sales are recorded that do not exist

RISK-CONTROL ACTIVITY RISK-MONITORING ACTIVITY

WHAT? For sales to be recorded there WHAT? A reconciliation of sales to
must be an accompanying shipping inventory shipments is prepared
notice
WHO? Accounting manager
WHO? Accounts clerk
HOW OFTEN? Monthly
HOW OFTEN? Daily as sales
are recorded HOW TIMELY? First business day after
the close of the month
HOW TIMELY? Same day as shipment
occurs

CONTROL ACTIVITY EVALUATION MONITORING ACTIVITY

CRITERIA EVALUATION CRITERIA
Were there any sales without shipping Is there verifiable evidence the
notices? reconciliations were performed?
Were sales recorded on day of shipment? Were the reviews performed?
Does a reconciliation of sales to shipping Were any variances between sales and
notices balance? shipping records explained?

FIGURE 9.5 Internal control documentation for sales

CHAPTER 9 Internal controls II 403

Control matrix
A matrix is any grid that combines multiple perspectives or attempts to integrate multiple perspectives.
Control documentation benefits from a matrix approach given that there are many perspectives to con-
trols. We may be interested in the risks within a process and the controls in place to address that risk, in
which case a matrix linking the two could be prepared. Alternatively, we may be interested in the execu-
tion of the various controls within a process, in which case a matrix of controls and characteristics could
be prepared. This leads to the possibility of numerous matrix possibilities for documenting controls.66
While research has acknowledged that control matrices can be time-consuming to prepare,67 the ben-
efits in terms of the perspective they provide on a system can be useful to those within the organisation.
Accordingly, preparation of a control matrix was proposed in the COSO report and provides a way of
linking the operation of the control activities to the control objectives of an information system.

9.10 The limitations of controls

LEARNING OBJECTIVE 9.10 Evaluate the effectiveness and limitations of a control system.
Looking at the concept of internal controls from the previous chapter, the emphasis was on the part
of the COSO definition that contained the words ‘reasonable assurance’ and the part of the Australian
Standard on Assurance Engagements ASAE 3150 definition that contained the words ‘which may pre-
vent achievement of control objectives relating to an entity’s systems’. Both of these quotes have sig-
nificant implications for the effectiveness of the internal control system. Effectively, what these simple
quotes do is provide a qualification on the effectiveness of any internal control system. The impact of
the words ‘reasonable assurance’ is that, even if an organisation has an internal control system in place,
problems can still occur. An internal control system is not a rock-solid guarantee that the organisation’s
objectives will be attained or that errors and illegal activity will not occur in the organisation.

Threats to an organisation’s objectives

CPA Australia identifies five reasons an internal control system does not provide 100 per cent assurance
that an organisation’s objectives will be achieved.68 These five reasons are judgement error, unexpected
transactions, collusion, management override and weak internal controls. You can also add to this list the
possibility of conflicting signals being given in the organisation’s operations.69
Judgement error
Decisions that require human judgement are always prone to human error. The reality is that it is not
possible to be 100 per cent right 100 per cent of the time. Any control procedure that requires an element
of human judgement is therefore prone to error. For example, organisational policy may be to hire
employees with suitable background qualifications, three professional referees and a strong character
background. In applying this policy to hiring staff, someone must make a judgement on what is a suit-
able background qualification and exactly what constitutes a strong character. Even if such checks are
applied perfectly, there is still the chance that the applicant has set up favourable referees to paint an
overly favourable picture.
Unexpected transactions
Control systems are usually designed around the typical transactions a business undertakes and the typical
errors or threats that apply to those transactions and the environments in which they occur. However, the
designers of a control system are not clairvoyants — they cannot predict every possible outcome and
every future event. Therefore, there will be events or transactions that were unanticipated when the con-
trol system was put in place. A sound control environment accompanied by a strong emphasis on ethical
and responsible behaviour can assist employees in carrying out these unexpected transactions, as can
regularly reviewing the controls and their appropriateness to the business environment.

404 PART 2 Systems characteristics and considerations

Collusion
Collusion is the situation where two or more people conspire to jointly commit a fraud against the organ-
isation. Recall the emphasis on the importance of segregation of duties as a way of restricting fraudulent
behaviour. The idea mentioned was that authorisation for a transaction that affects an asset should be given
by someone different from the person who has physical custody of the asset, and these two individuals
should be different from the individual who has record keeping responsibilities for the asset. In a large
organisation this is relatively easy to implement, because there will be many staff members. This makes
division of responsibilities in such a way reasonably practical. Unfortunately, it is by no means a foolproof
approach. While separation of duties makes it more difficult for an employee to defraud the organisation,
it does not make it impossible. If the employees responsible for custody, authorisation and record keeping
decide to collude, or work together, to defraud the organisation, then there is little the organisation could
have done to prevent it. From an organisation’s perspective, the logic is that the more people who have to be
involved in a fraud, the greater the chance of one of them slipping up and exposing the fraudulent activity.
Despite the theoretical effectiveness of segregation of duties, it does have one inherent limitation if one
tries to apply it to environments other than that of a large firm — simply put, as organisation size decreases,
application of segregation of duties becomes increasingly difficult, to the point of almost being an imposs-
ibility. From a practical point of view, they simply may not have sufficient staff members to properly
enforce adequate separation of duties, with the cost of increasing staff to make it a practical alternative out-
weighing the expected benefits. In such an environment the organisation must rely on what are best termed
‘social controls’ to promote the ‘right behaviour’. An example of such a social control is the fear of being
caught committing fraud and the shame that is attached to it. Alternatively, a strong managerial presence
and close relationship with and monitoring of employees can deter employees from committing such acts.
Management override
When first introducing controls the idea was mentioned that an organisation’s management plays a
critical role in the development of an internal control system. This, however, also exposes a weakness
in the internal control structure — that controls are only effective in so far as management is ethical
and responsible in promoting ‘good’ behaviour throughout the organisation. Looking at a sales scenario
where sales staff are only allowed to authorise credit sales up to $1000 and approval of a manager must
be obtained for sales greater than this amount. This control will work at stopping inappropriate approval
of sales at the lower level, but management has the power to override the control and approve large-
value sales. So, if management shows care and due process in checking sales before they are approved,
the control will be effective. However, if a manager merely ‘rubber stamps’ large-value sales, then the
control will be ineffective in its operation. Within the organisation, any person who has the authority to
override a control’s operation represents a potential threat to the control system’s effectiveness.
Weak internal controls
Put simply, and possibly quite obviously, a threat to internal control represents controls that are poorly
designed or weak in their application. Controls that purport to achieve an aim but do not, or that are
designed with inadequacies, obviously present a limitation to an internal control system’s ability to
achieve its objectives. Often, in designing a control system, it will be the simple things that are over-
looked. For example, an organisation wants to ensure that it pays its bills once and only once — after
all, you do not want to pay for something twice! A simple control to achieve this aim is the cancellation
of invoices once they have been paid.70 This can be performed by stamping the word ‘PAID’ across the
invoice, or drawing a line through it. This relatively simple control can be extremely effective in pre-
venting duplicate payments.
Conflicting signals
A final threat to an internal control system’s operation is the possibility that different signals are being
sent by management to employees. On the one hand, management may give the message that honest
and ethical behaviour is the priority of the organisation, yet it may design performance measurement

CHAPTER 9 Internal controls II 405

schemes that contradict this message. Take the example of a salesperson who is employed to sell a
product. This employee is paid a basic retainer, which makes up about 10 per cent of his or her salary.
The remaining income is derived from sales commissions, based on the value of sales he or she is able
to generate in each calendar month.
Given this compensation scheme, what type of incentive does such a system create for that sales-
person? The obvious temptation, if business is low in a particular month, is to record a few fictitious
sales towards the end of the bonus calculation period to ensure that a bonus is received. From the organ-
isation’s perspective this is obviously undesirable, since transactions are being recorded that have not
occurred, and potentially these could be to nonexistent customers. This is a breach of the principles of
existence and occurrence. The salesperson has merely responded to the pressures imposed by manage-
ment’s compensation policies, and in the process has violated the ideas of honest and ethical behaviour
as well as the reliability of the data that enter the information system. The organisation has implicitly
created the incentive for the sales staff to commit fraud by logging false sales. So in designing policies
and procedures, management should consider whether it is parsimonious with the overall environment
that it is trying to promote.
From this discussion it begins to be clear how internal controls are only able to provide reasonable assur-
ance that an organisation’s goals are being attained. The control environment, particularly management’s
attitude and philosophy style, can play a big part in limiting the threat of many of the factors discussed in the
preceding paragraphs, but it is by no means a total guarantee that the control system is infallible.

Threats to internal controls

In addition to the factors identified by CPA Australia, Rogers et al.71 identify eight factors that can pose
as threats to internal controls. These factors are: management incompetence; employee turnover; external
factors; fraud; complexity of transactions; complexity of organisational structure; regulatory environ-
ments; and information technology. A selection of these factors is briefly discussed in the following
sections.
Management incompetence
Since management has the overall responsibility for the establishment of internal controls and is signifi-
cant in the effectiveness of the overall control environment, any incompetence at the top can flow down
and impact on the remainder of the organisation. Alternatively, a panel of skilled board members may
not have the expertise to deal with some matters that may confront an organisation. One possible way to
circumvent this risk is to encourage the use of independent consultants for advice on business problems
for which the board does not have adequate skills or expertise.
External factors
As was discussed earlier, there are external factors beyond our control that can have dramatic impacts on
an organisation. Natural disasters, fires and so on can all affect a business despite the best-laid internal
control system. While the act itself may not be preventable, the adequacy of an organisation’s disaster
recovery plan will determine their ability to recover and return to normal operations.
Fraud
The risk of those within the organisation working around internal controls for their own gain is some-
thing that an organisation needs to be aware of. Where management has authority to work around con-
trols or approve events, this use of authority is a risk. At lower levels, this risk can come about through
collusion between employees. This scenario may be the result of employee incentive schemes that
unwittingly promote fraudulent behaviour.
Regulatory environment
Changes in the regulatory environment can impact the way that organisations operate. An example of
this was the introduction of the Sarbanes–Oxley Act in the United States, with its introduction in some

406 PART 2 Systems characteristics and considerations

situations requiring changes in the way internal controls were implemented and documented within
organisations. While it is US legislation, its effect is felt by any company that is monitored by the SEC
in the United States, making its impact wide reaching.72 Being unaware of changes in the regulatory
environment exposes an organisation to risk. This risk, however, can be reduced through the use of
appropriate outside expertise and professional advice.
Information technology
Information technology is in a constant state of flux. Threats from viruses and other malicious software
and email attacks (e.g. phishing) mean that organisations face new strains of threats to their information
technology resources. An example of this type of threat occurred when one of Australia’s largest banks,
the National Australia Bank, had its website attacked by a series of denial-of-service attacks, causing the
bank’s website to fail.

SUMMARY
9.1 Explain the importance of control activities in the accounting process.
The accounting process aims to capture data about business transactions and processes and store data, so
financial statements can be prepared for various user groups. In this process, data inputs must be gath-
ered and entered into the system and data needs to be updated and moved between different locations,
creating the risk of errors. The accounting process therefore relies on control activities that operate to
prevent, detect or correct any errors or irregularities and help achieve reliable and accurate reporting.

9.2 Evaluate internal controls as general or application.

Internal controls can be classified in a range of ways. The classification of general and application con-
trols sees the classification based on the role controls play as part of the broader information system
versus specific-to-business processes. Application controls relate to specific business processes and typi-
cally to control over the inputs, processing and outputs within those processes. General controls relate
across the computerised information system and provide the foundation on which application controls
operate. Internal controls can be applied to the different stages that data goes through in the organ-
isation: input, processing and output. The input/processing/output classification relates to the stage in
the data processing cycle that application controls operate. Taking a functional perspective, a preventive/­
detective/corrective classification looks at whether the control activities avoid, alert to or correct prob-
lems within a system.

9.3 Evaluate controls relating to the stages of data processing and COSO and COBIT.
Data processing within the organisation goes through several stages, including data collection, input, pro-
cessing, output and storage. In each of these stages there are risks that are addressed by the application
of control activities. The table presented in the chapter combines these aspects, showing the different
stages and examples of typical control risks and control activities. The COBIT framework provides an IT
control framework for organisations to apply across the stages of IT use within the organisation.

9.4 Describe the aims of a computerised accounting information system.

A computerised accounting information system operates with several aims, including authorisation, com-
pleteness, accuracy of recording and timeliness. These aims relate to ensuring that the events entering
a system are recorded accurately, that all events are recorded, that events are correctly approved before
they occur and that the system operates in a timely manner.

9.5 Explain and provide examples of general controls.

General controls are those that relate to the entire computerised information system. They can include
such things as access to the system, systems development procedures, authenticating users and backup
procedures and policies.

CHAPTER 9 Internal controls II 407

9.6 Explain and provide examples of application controls.
Application controls are designed around specific systems or business processes and the risks identified
within the processes. Application controls typically focus on the stages of data processing within a busi-
ness process (input, processing and output) and can be manual or computer executed.
9.7 Evaluate the operation and components of a disaster recovery plan.
A disaster recovery plan is designed to facilitate a business’s quick re-establishment in the event of a
disaster. It will consider issues of data recovery, technology replacement, restoring business relationships
that are critical to the business’s operations, as well as ensuring that people within the organisation are
aware of how the disaster recovery plan operates.
9.8 Critique the execution of control activities.
Control activities can be either manually or computer executed. Each execution method can present
advantages and disadvantages. Manual controls offer flexibility but can suffer from inconsistent appli-
cation. Computer-executed controls will be applied consistently and in a timely manner but can be
inflexible in application and are dependent on a sound set of general controls.
9.9 Demonstrate the different techniques for documenting a control system.
At an overall level, the control matrix shows the control objectives of a control system, how they would
ideally be attained and whether they actually exist within a system. Australian Auditing Standards pro-
vide guidance on some of the forms of documentation that may be used, including narrative descriptions,
questionnaires, checklists and flowcharts.
9.10 Evaluate the effectiveness and limitations of a control system.
It should be remembered that internal controls are not a guarantee against errors or irregularities. They
cannot guarantee that the organisation’s objectives will be achieved. Limitations that pose threats to an
organisation’s objectives are related to judgement error, unexpected transactions, collusion, m ­ anagement
override, weak internal controls and the possibility of conflicting signals being given in the organ­isation’s
operations. Factors that pose a threat to internal controls are management incompetence, external factors,
fraud, the regulatory environment and information technology.

KEY TERMS
Accuracy The aim of making sure that all data that enters the system are correct and reflect the actual
events that are being recorded.
Application controls Manual or automated procedures that typically operate at a business process
level and apply to the processing of transactions by individual applications.
Authorisation Ensuring users have correctly defined access to information within a system and that
transactions are executed and recorded by people with the appropriate authority.
Batch processing Data from transactions are accumulated in a group or batch and processed together.
Batch total A total that is added to a batch of documents and is used to make sure that all documents
in the batch have been correctly processed. A batch total is usually a summation of data items with
some meaning (e.g. a total of the individual invoice amounts for a batch of invoices). See also hash
total.
Cold site An available office with basic telephone and electricity supplies ready for use should they
be required.
Completeness The aim of ensuring that all events that occur are recorded within the system.
Corrective controls Controls designed to correct an error or irregularity after it has occurred.
Detective controls Designed to alert those involved in the system when an error or anomaly occurs.
Disaster recovery plan The strategy that the organisation will put into action in the event of a disaster
that disrupts normal operations in order to resume operations as soon as possible and recover data
that relate to its processes.

408 PART 2 Systems characteristics and considerations

General controls Policies and procedures that relate to many applications and support the effective
functioning of application controls.
Hash total A total that is similar to a batch total but the number that is added has no meaning by itself
(e.g. a hash total of customer numbers). See also batch total.
Hot site A separate facility located away from the organisation’s usual premises that contains offices
and the necessary resources (such as IT, telecommunications and data) to get the business back up
and running in a minimal amount of time after a disaster occurs.
Independent review A control tool where the work of one person is reviewed by another, thus
creating accountability.
Information processing controls Controls put in place within the organisation to work towards the
accuracy, completeness and authorisation of transactions.
Input accuracy The aim of ensuring all data entered into the system are correct.
Input completeness The aim of ensuring all transaction events and all required data relating to those
events are captured within the system.
Input controls Controls with the aim of detecting errors or irregularities at the time data are first
entered into the system.
Input validity The aim of ensuring that data entered into the system are in the correct format and valid.
Online data gathering and batch processing Data from transactions are stored immediately but
related data files are updated in a batch.
Online real-time data processing Data from transactions are captured immediately and the associated
data file is updated immediately.
Output controls Controls designed to protect the outputs of the system.
Performance reviews Activities that involve some form of review or analysis of performance.
Physical controls Controls that are put in place to physically protect the resources of the organisation.
Preventive controls Controls designed to stop errors or irregularities occurring.
Processing controls Controls that operate with the aim of detecting any errors or irregularities during
the processing of data.
Segregation of duties The concept that certain key functions are incompatible and should not be
performed by the same person.
Timeliness The aim of ensuring that information and data are available for users when required.

DISCUSSION QUESTIONS
9.1 Explain the following using examples.(LO2)
(a) General controls.
(b) Application controls.
9.2 You work for a business that has just established a new data processing centre. In a conversation with
one of the directors over lunch one day, you get on to the topic of controls and the design of controls
for the new centre. Proudly, the director boasts, ‘We have the most hi-tech biometric controls in place.
No unauthorised access to the centre is possible. The programmers are able to get on with their day-
to-day duties of developing programs and managing the organisation’s data resources.’
You are slightly concerned by this statement and immediately think back to appropriate controls
for implementation in the information systems environment — one of which is segregation of
duties.(LO5)
(a) What are the faults in the director’s statement?
(b) Can the organisation rely on biometric controls alone?
(c) How can separation of duties be applied in the information systems area?
(d) What are the critical functions that should be separated?
(e) What are the risks if these functions are not separated?

CHAPTER 9 Internal controls II 409

9.3 Define the following. (LO6)
(a) What is the relationship between a turnaround document and application controls?
(b) Five examples of turnaround documents. Discuss how turnaround documents help to achieve
the aims of input accuracy and input completeness.
9.4 Explain situations where manually performed control activities are particularly suitable. (LO8)
9.5 Describe the advantages of computer-executed control activities. (LO8)
9.6 Explain, using an example, why computer-executed controls rely on a sound set of general
controls. (LO8)

SELF-TEST ACTIVITIES
9.1 Examples of preventive controls to prevent incorrect data entry into a sales system include:
(i) validity checks, (ii) range checks, (iii) completeness checks, (iv) run-to-run total checks,
(v) redundant data checks. (LO2)
(a) i, ii, iii and iv
(b) ii, iii, iv and v
(c) i, iii, iv and v
(d) i, ii, iv and v
(e) i, ii, iii and v
9.2 The use of biometric identification techniques on an entrance to the computer processing centre is
an example of a: (LO2)
(a) preventive control.
(b) detective control.
(c) corrective control.
(d) application control.
(e) access control.
9.3 An organisation is concerned about the possibility of sales to false and nonexistent customers being
entered into its sales system by sales staff. The best control to prevent this problem would be: (LO6)
(a) calling a random sample of customers to ensure they exist.
(b) having sales staff maintain a customer master file.
(c) having a customer master file maintained independent of sales.
(d) having a policy of making only in-store sales (e.g. having no phone or web-based orders).
(e) proper screening of sales staff before hiring them.
9.4 Select the best pair of terms to complete the following statement: The threat of collusion
among employees can be reduced by the application of (i)___________, which entails
(ii)______________. (LO8)
(a) (i) organisational policies, (ii) having clearly defined job descriptions.
(b) (i) organisational policies, (ii) specifying procedures for the authorisation, custody and record
keeping relating to assets.
(c) (i) separation of duties, (ii) keeping employees separate from one another.
(d) (i) general controls, (ii) having a clear set of organisational policies, such as job notation and
forced annual leave.
(e) (i) separation of duties, (ii) keeping authorisation, custody and record keeping separate.

PROBLEMS
9.1 Classify the following control activities as general or application and explain your reasoning. (LO1)
(a) Employees have a password to gain access to the system.
(b) When sales are entered, the system retrieves customer details based on the customer number.
(c) A check is performed to identify if all cheques can be accounted for.

410 PART 2 Systems characteristics and considerations

 (d) Systems development is subject to sign-off by the CIO before it can take place.
(e) Virus definitions are updated daily.
(f) The sales manager must approve all discounts for items sold below their sticker price.
9.2 A sales system for a small retail store is described in the following paragraph. Once you have read
the paragraph, identify any risks within the system, the potential consequences of these risks, and
controls that could be implemented to combat these risks. (LO2)

The sales system

As a sale occurs, customer details including customer number and address, as well as the items pur-
chased, are written on a blank invoice form. Item descriptions, quantity sold and unit price are also filled
in, with the sales staff having some discretion in setting the unit price for situations such as bulk pur-
chases or repeat customers. These invoice forms are collected at the end of the day and keyed in to the
computer, with an invoice number assigned to invoices as they are keyed in. This number is recorded
on the store copy of the invoice. Any new customers are added to the customer master list as their
sales are entered and any details not gathered on the invoice are left blank. Data are stored on a cen-
tral server and this server is backed up monthly. The system is also connected up to the organisation’s
suppliers and used to order goods.

9.3 Explain, using an example, how batch totals can achieve the dual aims of input accuracy and input
completeness. (LO4)
9.4 Conduct a web search for some examples of internal controls that have failed to operate
effectively. For the cases you have identified, answer the following questions: (LO6)
(a) What factors led to the failure of these controls?
(b) Could the failure have been avoided? If so, how?
9.5 Turn ’Em Out is a fashion company that sells clothes to retail stores and individual customers,
provided that they are registered as a customer. This eliminates the need for off-the-street
sales. The organisation recently received a purchase order. The steps that are subsequently
followed are:
(1) Customer service representative prepares a sales order (three copies).
(2) Send the sales order to the accounts department and sales department.
(3) The accounts department and sales department will enter the order into the system.
(4) The computer will capture the data and store it in a temporary file, updating the inventory,
sales and accounts receivable files at the end of the day.
(5) Print a picking slip and invoice and send it to the warehouse.
(6) Pick the goods.
(7) Attach picking slip and invoice to the goods.
(8) Send goods to the customer.
Analyse the process by breaking it up into the stages of authorisation, input, processing, output,
and external data stages, as was discussed in reference to COBIT in the chapter. For each stage,
state the aims, control issues and controls that could be used by Turn ’Em Out. (LO8)
9.6 The payments department at Slick Sales has issued a cheque for an invoice it has received from
Office Supplies Ltd. The payables clerk has three documents: (1) a receipted purchase order
(figure 9.6), (2) a receiving report (figure 9.7), and (3) an invoice (figure 9.8). The clerk has
prepared the accompanying cheque and had it signed, ready for sending (figure 9.9). (LO8)
Required
(a) Explain how the purchase order, receiving report and invoice play an important role in the
authorisation of payments to accounts payable.
(b) Analyse the documents shown and determine if the clerk should have prepared the cheque and
if it should be sent off to the supplier. Justify your conclusion.
(c) What controls should be in place during and subsequent to cheque preparation?
(d) Discuss the use and function of the remittance advice that is contained as a part of the tax invoice.

CHAPTER 9 Internal controls II 411

 PURCHASE ORDER
No. 64971
Slick Sales
45 Westend Road
Melbourne
ABN: 57 999 888 777

TO: SENT
Office Supplies Ltd 05 MAY 15
5 Broadway Road
East Melbourne

Date Ordered: 5/5/2015 Purchase Req No.: 54937

Product No. Description Price Quantity Total
101-A1 A4 Copy Paper 500 sheets 5.50 10 55.00
202-C4 Printer cartridge – Laserjet 68.00 5 340.00
054-B2 Electronic stapler 75.00 2 150.00
391-J8 Paper files – pack of 100 35.50 4 142.00
452-P3 Binder – A4 2 ring large 6.75 2 13.50
TOTAL 700.50

Prepared By: Approved By:

Sam Toms Tim Lees
FIGURE 9.6 Purchase order

RECEIVING REPORT
Slick Sales No. 68431

Purchase Order No: 64971 Entered By: Louise Hanninton

Goods Received From: Office Supplies Ltd Receipt Date: 12/5/15

Product No. Description Quantity Comments

101-A1 A4 Copy Paper 500 sheets 10 Condition OK
202-C4 Printer cartridge – Laserjet 5 Box damaged, item OK
054-B2 Electronic stapler 2 Condition OK
391-J8 Paper files – pack of 100 4 Condition OK
452-P3 Binder – A4 2 ring large 2 Condition OK

Report Goods
Prepared By: Received By:
Julie Mantini Ross Scambly
FIGURE 9.7 Receiving report

412 PART 2 Systems characteristics and considerations

 TAX INVOICE
No. 159473
Office Supplies Ltd
5 Broadway Road
East Melbourne
ABN: 10 567 893 111

To: Acct No.: S1149

Slick Sales Terms: 2/10, n/35
45 Westend Road Payment Due: 29/06/15
Melbourne

Invoice Date: 25/5/2015 Purchase Order No.: 54937

Product No. Description Price Quantity Total

101-A1 A4 Copy Paper 500 sheets 5.50 10 55.00
202-C4 Printer cartridge – Laserjet 68.00 5 340.00
054-B2 Electronic stapler 75.00 3 225.00
391-J8 Paper files – pack of 100 35.50 4 142.00
452-P3 Binder – A4 2 ring large 6.75 2 13.50
SUB TOTAL 775.50
+ GST 77.55
TOTAL 853.05

PLEASE QUOTE YOUR ACCOUNT NUMBER WHEN ENQUIRING ABOUT INVOICE DETAILS

REMITTANCE ADVICE
Please return with payment

Account Number: S1149 Due Date: 29/06/15

Account Name: Slick Sales Invoice No: 159473
Amount Owing: 853.05

OFFICE USE ONLY

Date Received: Date Entered:
Received By: Entered By:
Amount Received: Cheque Number:

FIGURE 9.8 Tax invoice

CHAPTER 9 Internal controls II 413

 TRIMOND BANKING GROUP Date 30-05-15
Cheque 101 349 Victoria Avenue
Melbourne East
Payee: Office
Supplies Ltd
For: Office Pay Office Supplies Ltd Or bearer
Supplies Invoice 159473 The sum of Eight hundred and fifty-three dollars $853.05
and five cents
Date: 30-05-15 Slick Sales

Amount: 853.05
|| 648 317 101||

FIGURE 9.9 Cheque

9.7 Review the following website on spreadsheet errors: www.eusprig.org/horror-stories.htm. Select

one of the stories that interest you. (LO10)
Required
(a) What was the error and what were the implications of this error?
(b) Why do organisations use spreadsheets? What are the benefits and limitations?
(c) What applications (software tools) could be used to avoid these errors?
9.8 CPA Australia’s advisory guide on employee fraud identifies some typical ways that fraud is
carried out. These include:73 (LO8)
   i. creating ‘ghost’ employees or not deleting ex-employee records and having the salary of
these ‘ghost’ employees paid into the fraudster’s bank account
   ii. creating bogus suppliers, with payment being made to the fraudster’s bank account
iii. creating bogus purchase orders of a bona fide supplier and substituting the supplier’s bank
account details with fraudster’s bank account details
  iv. obtaining kickbacks or bribes from suppliers or contractors (as an inducement to purchase
from them)
   v. associates of the staff providing services to the business at inflated prices
  vi. using business resources for personal use
  vii. submitting inflated/bogus reimbursement claims
viii. manipulating financial data to receive performance-based bonuses
ix. faking time sheets
   x. making private purchases through business accounts/business credit cards
  xi. providing discounted (or free) goods or services to friends and associates.
Required
For each of the above:
(a) suggest a possible application control that could deal with the fraud
(b) classify the control as preventive, detective or corrective and justify your classification
(c) explain how the control addresses the fraudulent activity.
9.9 The following purchase order (figure 9.10) was sent by Giddy Up Pty Ltd to Stable Supplies Ltd.
The second copy of the purchase order (figure 9.11) from Giddy Up was sent to the receiving
department and was stamped and signed when the goods were received. (LO9)

414 PART 2 Systems characteristics and considerations

 Required
(a) Identify the control features of both documents.
(b) Discuss the functioning of the control features in both documents.
(c) What controls could have been present when the purchase requisition details (not shown) were
entered into the computer and the purchase order generated?

PURCHASE ORDER SUPPLIER

COPY
Giddy Up Pty Ltd No. 64971
1 Winning Post Lane
Flemington
ABN: 11 111 111 111

To:
Stable Supplies
4 Fetlock Road
Caulfield

Order Date: 1/11/2015 Purchase Req No.: 61111

Product No. Description Price Quantity Total

A-187 Barrier blanket 150.00 5 750.00
A-199 Riding crop 45.00 4 180.00
C-297 Racing saddle – light 300.00 1 300.00
G-851 Norton bit 80.00 3 240.00
TOTAL 1470.00

Approved
Prepared By:
By:
Mary Bethany Kym Dilaney
FIGURE 9.10 Purchase order sent to vendor

CHAPTER 9 Internal controls II 415

 PURCHASE ORDER RECEIVING
DEPT COPY
Giddy Up Pty Ltd
1 Winning Post Lane No. 64971
Flemington
ABN: 11 111 111 111

To: Received
Stable Supplies 07 NOV 15
4 Fetlock Road
Caulfield

Order Date: 1/11/2015 Purchase Req No.: 61111

Product No. Description Price Quantity Total

A-187 Barrier blanket
A-199 Riding crop
C-297 Racing saddle – light
G-851 Norton bit
TOTAL

Approved
Prepared By:
By:
Mary Bethany Kym Dilaney
FIGURE 9.11 Copy of purchase order routed to receiving department

9.10 For each of the following risks suggest a control that could be used to reduce it. (LO10)
(a) Entering negative values for order quantity in a sales order.
(b) Selling to a customer with an overdue account.
(c) Ordering from a nonexistent supplier.
(d) Paying for goods that have not been received.
(e) Entering an alphanumeric customer ID when the business policy is for numeric customer IDs.
(f) Misappropriation of goods by receiving staff, who also maintain inventory records.
(g) Ordering too much of a product.
9.11 An accounts payable process is documented in the flowchart in figure 9.12. Using this flowchart
as a reference: (LO10)
(a) write a brief narrative that describes the operation of the process
(b) identify any risks that are present in the system
(c) identify any controls that are present in the case and explain their operation and the risks that
they address
(d) identify any risks that do not have relevant control activities and discuss the internal control
activity that would be appropriate to address the risk.

416 PART 2 Systems characteristics and considerations

 Accounts clerk Computer Accounts manager

Purchasing Receiving Accounts A

Supplier Capture
department department payable
details
master data
Invoice or
Invoice or Purchase Receiving
remittance
remittance order report
advice
advice Purchase
Purchase
order master
order Receiving
Open data
orders report

Match
documents Purchase
Verify
order Search for due Cheques
cheque
Invoice or Receiving invoices
remittance report
advice
Purchase
Cheques
order
Receiving Invoice or
Prepare and
report remittance
record cheques
advice
Purchase
order
Enter payable
Receiving
details
report
Cash
Payable payments
details data
B Sign cheque and
cancel
Invoice or documents
remittance Purchase Cheques
advice order Remittance
Purchase Receiving advice Purchase
order report order
Receiving Cancelled Receiving
report invoice report
Supplier
Cancelled
invoice
A Closed
orders
A B

FIGURE 9.12 Flowchart of the accounts payable process

CHAPTER 9 Internal controls II 417

9.12 The sales and warehouse of Truly Legit, a retail company, operates as follows and is currently
under review.

Truly Legit is implementing a new credit sales approval system. Based on an analysis of their existing
sales data for credit sales in the financial year just ended the following data has been obtained.

Transaction value Total value Number of transactions % of sales

$1–$500 $357  950 1431 27.9

$501–$1000 $455  845 585 35.6

$1001–$2500 $287  675 145 22.5
$2500 $180  000   60 14.0
TOTAL $1  281  470 2221 100.0

The current system has a standard sales process whereby the sales person provides the approval and
authorisation for goods to be released by signing a sales order, a copy of which goes to the warehouse
and serves the dual purpose of a picking ticket and shipping authorisation. The documents are prepared
on computer by the salesperson, printed out and sent via internal mail at the end of the day to the
warehouse. If a new customer comes in off the street, then the sales person adds them to the system
immediately and gives them the default credit limit of $750. Customer credit limits are not checked
unless the customer name appears on a credit warning list, which is produced by the accounts receiv-
able division at the start of each month. All sales follow this process.
The stages of the COSO framework, as they apply to Truly Legit, are:
• Control environment: The board of directors is constantly receiving feedback from the various func-
tional divisions about their performance and meeting of targets. Additionally, the board places great
emphasis on corporate governance and has held numerous organisation-wide workshops and training
sessions for middle-level management to reinforce the importance of proper governance and control.
The board also has an audit committee, who monitor internal control functionality, which is comprised
wholly of non-executive directors.
• Risk assessment: Management is concerned about the following risks in the sales process.

Risk

• Sales to customers who have exceeded their credit limit

• Large transactions taking place without proper approval

• Fraudulent sales of low value entering the system

• Goods being shipped without proper authorisation

• Sales orders going missing between sales person and warehouse

• Customers’ records containing nonexistent customers

• Control activities.
• Information and communication.
• Monitoring. (LO3)

Required
(a) Using the COSO framework, derive control activities that could be implemented within the
sales process to overcome the risks involved.
(b) For each control activity that you identified in (a), identify the information and communication
necessary as well as how monitoring can occur to assess the process performance.

418 PART 2 Systems characteristics and considerations

9.13 Refer to AIS Focus 9.3, ‘Human error: the biggest problem’, and answer the following
questions. (LO6)
(a) Explain how the data entry errors could have been avoided in the article.
(b) Identify a control that could have been put in place to prevent or detect the errors described.
Explain how the control would have solved the problem.
(c) Recommend appropriate internal controls that you would expect to see implemented for the
problems described in the article.
9.14 Below is a description of a business process.

The computer system requires all users to log on with a user identification (their first initial and the first
six letters of their surname) and a password that is assigned to users when they join the firm (that is
unable to be changed). The users have access to the internet and several have installed Windows Live
Messenger and other chat programs on their machines.
The main task of John, one of the staff members, is to perform data entry. Each day he receives
a bundle of orders from the customer assistant, with John’s job being to enter the details into the
system. John first enters the customer name, address and contact number, then clicks on the ‘Next’
button to enter the items and quantities ordered by the customer. If the customer name is not pro-
vided, the computer will prompt John to go back and fill in the details before proceeding to the next
screen. In addition, the computer will only accept numeric values for the quantities ordered. Once
all orders are entered John clicks the ‘Done’ button and the computer displays the number of orders
entered on the screen. John usually ignores this, because by the time orders have been entered it is
usually lunchtime. (LO8)

Required
(a) Identify four risks in the process.
(b) Suggest an internal control for each risk (the control may be mentioned in the case or
missing and you think it should be applied).
(c) Indicate whether the control is present or missing in the case.
(d) Classify the control as general or application.
(e) Identify the control goal that the control addresses.
(f) Classify the control as manual or computerised.
Use the template matrix shown below to document your answer.

General/ Manual/
Risk Control Present? application Goal computerised

9.15 Explain why prenumbering source documents is a necessary but not sufficient condition for
completeness to be satisfied. (LO10)
9.16 Explain how edit checks can help to achieve the assertion of accuracy. (LO8)
9.17 Organisations are often subject to legal requirements, with controls put in place to meet
these. An example is the Privacy Act, which places restrictions on how data is to be
gathered, used and stored. It also addresses security of data and procedures for protecting
access to data.

CHAPTER 9 Internal controls II 419

 Required
(a) Explain why protecting data is an increasing challenge for organisations.
(b) Suggest organisational control activities that could be implemented to protect data. (LO10)
9.18 Organisations operate in a global economy that is increasingly complex because of changes in
regulatory environments and technological change. The risk of fraud has consequently increased.
Read the article by KPMG, ‘Fraud Risk Management: Developing a Strategy for Prevention,
Detection and Response’ at www.kpmg.com/AU/en/IssuesAndInsights/ArticlesPublications/
Documents/fraud-risk-management-strategy-prevention-detection-response-v2.pdf. (LO8, LO10)
Required
(a) Explain the issues raised in the report.
(b) What are the recommendations for management to ensure the identified risks are managed?
9.19 Find an example of a disaster recovery plan on the internet. (LO7)
Required
(a) Analyse the disaster recovery plan against the organisation’s objectives.
(b) Provide five recommendations for management on how the disaster recovery plan could be
improved.
9.20 Read the article by Robert Siciliano, ‘10 Unbelievable Identity Theft Cases’ at
www.huffingtonpost.com/robert-siciliano/10-unbelievable-identity_b_5239159.html. (LO10)
Required
(a) Select one of the identity theft examples and do your own in-depth investigation.
(b) Explain how the identity theft occurred and the controls that should have been in place to
prevent the theft of someone else’s identity.
9.21 Explain how the COSO and COBIT frameworks have changed from earlier versions. (LO3)

SELF-TEST ANSWERS
9.1 e, 9.2 e, 9.3 c, 9.4 d

ENDNOTES
1. Auditing and Assurance Standards Board 2015, Auditing Standard ASAE 3150 Standard on Assurance Engagements,
Assurance engagements on controls.
2. Auditing and Assurance Standards Board 2015, Auditing Standard ASAE 3150 Assurance engagements on controls, pp. 44–5,
www.auasb.gov.au/admin/file/content102/c3/Jan15_ASAE_3150_Assurance_Engagements_on_Controls.pdf.
3. Auditing and Assurance Standards Board 2013, Auditing Standard ASA 315 Identifying and assessing the risks of material
misstatement through understanding the entity and its environment, paragraph A96, www.auasb.gov.au/admin/file/content102/
c3/Nov13_Compiled_Auditing_Standard_ASA_315.pdf.
4. Auditing and Assurance Standards Board 2013, Auditing Standard ASA 315, paragraph A104.
5. Auditing and Assurance Standards Board 2013, Auditing Standard ASA 315, paragraph A105.
6. DPP (Cth) v. Hill and Kamay [2015] VSC 86, http://scv2.webcentral.com.au/judgments/pdfs/T0086.
pdf#page=1&navpanes=0&toolbar=1&scrollbar=1&pagemode=none, p. 59.
7. Russell, M 2015, ‘Insider trading masterminds Lukas Kamay, Christopher Hill jailed after Block bid’, The Sydney Morning
Herald, 17 March 2015.
8. Association of Certified Fraud Examiners, Inc 2014, Report to the nations on occupational fraud and abuse: 2014 global
fraud study, www.acfe.com/rttn/docs/2014-report-to-nations.pdf.
9. DPP (Cth) v. Hill and Kamay [2015] VSC 86.
10. DPP (Cth) v Hill and Kamay [2015] VSC 86.
11. ISACA 2014, IT Control objectives for Sarbanes–Oxley: using COBIT® 5 in the design and implementation of internal
controls over financial reporting, 3rd edition, ISACA, Rolling Meadows, Illinois, IL.
12. ISACA, Application controls AC1 to AC6, www.isaca.org/popup/Pages/ApplicationControls.aspx.
13. ISACA, Application controls AC1 to AC6.
14. Jain, AK, Ross, A & Prabhakar, S 2004, ‘An introduction to biometric recognition’, IEEE Transactions on Circuits and
Systems for Video Technology, Special Issue on Image- and Video-Based Biometrics, vol. 14, no. 1, www.citer.wvu.edu/
members/publications/files/RossBioIntro_CSVT2004.pdf.

420 PART 2 Systems characteristics and considerations

15. Association of Certified Fraud Examiners, Inc 2014.
16. PwC, Corruption: from the backroom to the boardroom, PwC’s 2014 Global economic crime survey: the Australian story,
www.pwc.com/gx/en/economic-crime-survey/pdf/australia-economic-crime-survey.pdf.
17. Ives, B, Walsh, K & Schneider, H 2004, ‘The domino effect of password reuse’, Communications of the ACM, vol. 47, no. 4, pp. 75–8.
18. Zviran, M & Haga, W 1999, ‘Password security: an empirical study’, Journal of Management Information Systems, vol. 15,
no. 4, pp. 161–85.
19. Adams, A & Sasse, MA 1999, ‘Users are not the enemy’, Communications of the ACM, vol. 42, no. 12, pp. 41–6.
20. Zviran & Haga 1999.
21. Gaw, S & Felten, E 2006, ‘Password management strategies for online accounts’, Symposium on Usable Privacy and Security
(SOUPS) 2006, 12–14 July, Pittsburgh, PA.
22. Ives, Walsh & Schneider 2004.
23. Ives, Walsh & Schneider 2004; Zviran & Haga 1999.
24. Zviran & Haga 1999.
25. Sampemane, G 2015, ‘Internal Access Controls’, Communications of the ACM, vol. 58, no. 1, pp. 62–5.
26. CEB, 2015 Audit plan hot spots, www.complianceweek.com/sites/default/files/CEB%20Audit%20Risk%20Hot%20Spots%20
2015.pdf.
27. Farahmand, F & Spafford, EH 2013, ‘Understanding insiders: an analysis of risk-taking behavior’, Information Systems
Frontiers, vol. 15, no. 1, pp. 5–15.
28. West, R 2008, ‘The psychology of security’, Communications of the ACM, vol. 51, no. 4, pp. xiii, 34–41.
29. Leviathan Security Group Inc. 2015, Value of cloud security: vulnerability, Seattle, WA, www.leviathansecurity.com/
wp-content/uploads/Value-of-Cloud-Security-Vulnerability.pdf.
30. Leviathan Security Group Inc. 2015.
31. Khan, AN, Mat Kiah, ML, Khan, SU & Madani, SA 2013, ‘Towards secure mobile cloud computing: a survey’, Future
Generation Computer Systems, vol. 29, no. 5, pp. 1278–99.
32. Choy, M, Leong, HV & Wong, MH 2000, ‘Disaster recovery techniques for database systems’, Communications of the ACM,
vol. 43, no. 11, pp. 272–80.
33. Maiffret, M 2014, ‘2014: The year of privilege vulnerabilities’, Dark Reading, www.darkreading.com/
vulnerabilities — threats/2014-the-year-of-privilege-vulnerabilities/a/d-id/1318187.
34. Hardekopf, B 2014a, ‘Neiman Marcus hack not as widespread as once feared’, LowCards.com, 27 February, www.lowcards.
com/neiman-marcus-hack-widespread-initially-feared-22793; Hardekopf, B 2015, ‘The big data breaches of 2014’, Forbes,
13 January, www.forbes.com/sites/moneybuilder/2015/01/13/the-big-data-breaches-of-2014/.
35. Hardekopf, B 2013, ‘40 million card accounts affected by security breach at Target’, LowCards.com, 19 December,
www.lowcards.com/40-million-card-accounts-affected-security-breach-target-21279.
36. Hardekopf, B, 2014b, ‘Home Depot breach hit 56 million credit and debit cards’, LowCards.com, 19 September,
www.lowcards.com/home-depot-breach-hit-56-million-credit-debit-cards-27571.
37. Dean, B 2015, ‘Why companies have little incentive to invest in cybersecurity’, The Conversation, 5 March, http://
theconversation.com/why-companies-have-little-incentive-to-invest-in-cybersecurity-37570.
38. Australian Government Department of Defence Intelligence and Security 2015, The Australian Government information
security manual: controls, www.asd.gov.au/publications/Information_Security_Manual_2015_Controls.pdf.
39. KPMG 2013, A survey of fraud, bribery and corruption in Australia and New Zealand 2012, www.kpmg.com/AU/en/
IssuesAndInsights/ArticlesPublications/Fraud-Survey/Pages/fraud-bribery-corruption-survey-2012.aspx.
40. Bloomberg BNA 2015, Top tax & accounting mistakes that cost companies millions, www.bnasoftware.com/PDFs/resource-
center/Whitepapers/Bloomberg_BNA_Top_Tax_Accounting_Mistakes_White_Paper.pdf.
41. Panko, RR & Salvatore, A 2010, ‘Revising the Panko–Halverson taxonomy of spreadsheet errors’, Decision Support Systems,
vol. 49, no. 2, February, pp. 235–44.
42. Mazars, n.d., The dirty dozen: 12 modelling horror stories & spreadsheet disasters, eBook, F1F9, London, www.f1f9.com/.
43. Mazars, n.d; Borwein, J & Bailey, D 2013, ‘The Reinhart-Rogoff error — or how not to Excel at economics’, The
Conversation, 23 April, http://theconversation.com/the-reinhart-rogoff-error-or-how-not-to-excel-at-economics-13646.
44. Boreham, T 2004, ‘New NAB boss to restore “pride”’, The Australian, 3 February, p. 1; Gluyas, R 2004, ‘Late-night call puts
Scotsman in top job’, The Australian, 3 February, p. 1.
45. Lightle, SS & Vallario, CW 2003, ‘Segregation of duties in ERP’, Internal Auditing, vol. 60, no. 5, pp. 27–31.
46. Lightle & Vallario 2003, pp. 27–31.
47. Lehman, MW 1999, ‘Searching for unusual transactions’, The Internal Auditor, vol. 56, no. 6, pp. 27–9.
48. Based on Richtel, M 2002, ‘Credit companies are growing wary of online betting’, The New York Times, 21 January, p. C1.
49. PricewaterhouseCoopers 2002, ‘Disaster recovery and business continuity planning, post 9/11’, The Secure Solution, April,
PricewaterhouseCoopers, www.pwcglobal.com.
50. Timson, L 2003, ‘Flirting with disaster’, The Sydney Morning Herald, 14 October.
51. AT&T 2002, ‘Survey finds many businesses still unprepared for disasters’, 27 August, www.att.com.
52. Timson 2003.
53. PricewaterhouseCoopers 2002.

CHAPTER 9 Internal controls II 421

54. Timson, 2003.
55. AT&T 2002.
56. Auditing and Assurance Standards Board 2015, Auditing Standard ASAE 3150 Standard on Assurance Engagements,
Assurance engagements on controls, p. 43, www.auasb.gov.au/admin/file/content102/c3/Jan15_ASAE_3150_Assurance_
Engagements_on_Controls.pdf.
57. Bierstaker, JL 1999, ‘Internal control documentation: which format is preferred?’, The Auditor’s Report, vol. 22, no. 2,
pp. 12–13.
58. Bierstaker, JL & Wright, A 2004, ‘Does the adoption of a business risk audit approach change internal control documentation
and testing changes?’, International Journal of Auditing, vol. 8, pp. 67–78.
59. Deloitte & Touche LLP 2003a, Moving forward — a guide to improving corporate governance through effective internal
control: a response to Sarbanes–Oxley, January, Deloitte & Touche USA, p. 6.
60. Bierstaker & Wright 2004.
61. Ernst & Young LLP 2003, Evaluating internal controls: considerations for evaluating internal control at the entity level, Ernst
& Young, New York.
62. Bierstaker & Wright 2004.
63. Deloitte & Touche LLP 2003a.
64. Deloitte & Touche LLP 2003b, The growing company’s guide to COSO, June, Deloitte & Touche LLP, New York, pp. 6–7.
65. Adapted from Deloitte & Touche LLP 2003b, p. 9. Reproduced with permission.
66. Ernst & Young LLP 2003.
67. Bierstaker & Wright 2004.
68. Campbell, S & Hartcher, J 2003, Internal controls for small business, CPA Australia, Melbourne, p. 12.
69. Deloitte & Touche LLP 2003b.
70. Campbell & Hartcher 2003.
71. Rogers, V, Marsh, TA & Ethridge, JR 2004, ‘Internal controls: winning the battles against risks’, Internal Auditing, vol. 19,
no. 4, pp. 28–34.
72. International Federation of Accountants 2006, Internal controls — a review of current developments, International Federation
of Accountants, New York.
73. CPA Australia 2011, ‘Employee fraud’, CPA Australia, Southbank, Victoria, p. 5.

ACKNOWLEDGEMENTS
Figure 9.2: © The Apache Software Foundation.
Photo: © Andrey_Popov / Shutterstock.com.

422 PART 2 Systems characteristics and considerations

PART 3
Systems in action
Part 3 of the text examines the application of the concepts introduced in part 2 to specific
examples of business cycles or processes that operate within a wide range of businesses.
These examples of transaction cycles that occur within a business are central to the business
being able to attain its objectives. Each cycle operates through a series of activities aimed
at achieving a particular goal or solving a particular problem within the organisation. Each
chapter outlines the particular business process and the appropriate systems documentation.

10 Transaction cycle — the revenue cycle 426

11 Transaction cycle — the expenditure cycle 481

12 Transaction cycle — the general ledger and financial reporting cycle 538
 Figure P3.1 introduces the business processes described in detail in the following three chapters; it
depicts the interrelationships between these processes, and the interactions between the processes and
external entities. The following discussion examines the process interrelationships
and related risks.

Operational
Customer
departments

Inventory
department

General ledger &

financial reporting
(1) process (3)
Revenue process Chapter 12 Expenditure process
Chapter 10 (2) (4) Chapter 11

Courier

Bank External users

Supplier

FIGURE P3.1 Integrated process perspective

The revenue cycle (chapter 10) commences when a customer indicates they want to purchase
a product and ends after the product has been delivered and payment received. The level of
activity within the revenue cycle drives the activity levels for all the other business processes.
The revenue cycle has a large number of external interactions with customers.
The expenditure cycle (chapter 11) commences when a section of the organisation reports a need
for goods or services to be provided and ends when the goods or services have been received
and paid for. The expenditure cycle has a large number of external interactions with suppliers.
After the transaction cycles have been successfully completed, details are sent to the
general ledger and financial reporting cycle (chapter 12) to enable updating of the general ledger
and subsequent financial reporting. The revenue cycle provides details of invoices raised by the
billing system and payments received from customers, and the expenditure cycle forwards details
of payments established and made. These data are validated, consolidated, adjusted and used
for reporting and analysis of the organisation’s performance. Any errors made here can have
serious consequences; reporting incorrect values can result in poor internal decision making,
issues with capital markets and the possibility of regulatory prosecution if corporate laws
are breached.

424 PART 3 Systems in action

Table P3.1 details the major data flows between the transaction cycles.

TABLE P3.1 Data flows between the transaction cycles

Flow # Initiating cycle Receiving cycle Flow description

1 Revenue General ledger & Accounts receivable sends details of invoices raised by the
financial reporting billing system and payments received from customers to
finance to enable updating of the general ledger and the
subsequent financial reporting.

2 General ledger & Revenue Management reports are prepared to enable management of
financial reporting the revenue cycle.

3 Expenditure General ledger & Accounts payable sends details of payments established
financial reporting and made to finance to enable updating of the general
ledger and the subsequent financial reporting.

4 General ledger & Expenditure Management reports are prepared to enable management of
financial reporting the expenditure cycle.

PART 3 Systems in action 425

CHAPTER 10

Transaction cycle —
the revenue cycle
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

10.1 reflect on the key objectives and strategic implications of the revenue cycle
10.2 evaluate common technologies underpinning the revenue cycle
10.3 recognise revenue cycle data and key revenue business decisions
10.4 summarise and prepare documentation synthesising the primary activities in the revenue cycle and
the data produced by these activities
10.5 assess risks and compose control plans pertinent to the primary activities in the revenue cycle
10.6 justify metrics to monitor revenue cycle performance.
Introduction
Revenue-related activities are some of the most essential conducted by an organisation. The revenue
cycle commences when a customer indicates they wish to purchase a good or service and ends when
payment has been received. During the process, sales need to be properly authorised and correctly
recorded. Goods must be packed and shipped to customers in a timely and correct manner. Customers
need to be billed the right amount, at the right time, for the goods and/or services supplied. Finally, pay-
ments received from customers need to be quickly and accurately receipted and banked.
This chapter commences with an overview of the revenue cycle and then considers the strategic impli-
cations of that process. Technologies that underpin the cycle are discussed and then the data produced
and consumed during the cycle activities are identified. Typical business decisions are examined, along
with some of the primary considerations related to those decisions. A revenue cycle is fully documented
using process maps, data flow diagrams (DFDs) and flowcharts, along with a set of tables containing
additional details to aid in understanding the process activities and the related risks and controls of
the activities. Finally, issues relating to measuring performance of the revenue cycle are discussed and
examples of performance metrics suitable for measuring revenue cycle performance are provided.

10.1 Revenue cycle overview and key objectives

LEARNING OBJECTIVE 10.1 Reflect on the key objectives and strategic implications of the revenue cycle.
For an organisation to prosper it is essential that the revenue cycle is well managed and controlled. Marketing,
sales and finance are the organisational units that have primary responsibility for the revenue cycle. Sales are
the primary driver of all organisational activity and the most intensive customer contact point. Sales are easily
lost if consumers are confronted with an inadequate sales process or improper billing practices. Losses are
likely if deliveries are not accurate, timely and well controlled. An inadequate revenue cycle, or failure to col-
lect revenues, can lead to declining sales, cash flow difficulties and, in the worst cases, potential insolvency or
cessation of the business. The organisational units most involved in the revenue cycle are shown in figure 10.1.

CHAPTER 10 Transaction cycle — the revenue cycle 427

 Chief executive
officer

Director Director Director Director Director

administration finance or logistics marketing sales
accounting

Funds Inventory Sales order

Personnel Advertising
disbursement control processing

Office Customer
Billing Purchasing
operations service

Tax planning Receiving

Maintain
Storage
accounts

Budgeting Production

Update
Shipping
accounting
records

FIGURE 10.1 Organisational units in the revenue cycle

Note: The dashed lines with the arrows show the business activities that each unit is responsible for.

The revenue cycle is conventionally divided into two major elements. The front end of the cycle is client
facing and is where the sales transaction takes place. The objective of the sales phase is to effectively conduct,
record and monitor sales of goods and services, and arrange the prompt supply of goods and services. Essen-
tially, staff involved in the sales phase need to make sure that the organisation provides the right product at the
right time to the right place. To achieve this objective, customer orders must be properly recorded and controlled,
sales should only be made to creditworthy customers and delivered goods must meet the customer’s needs.
Following directly on from sales is the accounts receivable phase, where the objective is to ensure pay-
ments for goods and services are correctly received, recorded and banked. This part of the cycle is some-
times referred to as ‘back-office’ or ‘back-end’ processing. The activities in this latter part of the cycle
are often carried out by staff who do not have the same direct contact with customers as the front-end, or
client-facing, staff who process sales. In order to maintain good client relationships the linkages between
the front-end and back-end revenue systems must be well defined. The accounts receivable phase needs
to make sure that customers are billed the right amounts for the right products, and that those amounts are
collected at the right time. This involves ensuring that customer invoices and receipts are prepared and
recorded in an accurate and timely manner, that cash receipts are protected from fraud and misuse, that
receivables balances are kept to a minimum level and that the organisation collects amounts owing to it on
a timely basis. A description of documentation commonly used in the revenue cycle is shown in table 10.1.

428 PART 3 Systems in action

 TABLE 10.1 List of source documents in a revenue cycle
Documents Description
Customer order Allows the customers to order goods from the organisation. This form can be in the form of
a customer’s purchase order prepared by the customer or a customer order form prepared
by a salesperson in the sales unit.
Order A copy of the customer order that is sent to the customer in acknowledgement of the
acknowledgement customer’s order. The order acknowledgement is often prepared by the salesperson who
receives the customer’s order form (or purchase order form).
Credit application A form that is prepared for a new customer applying for credit. The form shows the
customer’s financial position and the customer’s ability to repay any debts owing.
Sales order A formal document that is prepared using the customer order form. Multiple copies of the
document are also prepared to initiate shipment and receive payments from customers.
The sales order form is prepared by a salesperson in the sales unit.
Goods packing A document that is generated by the shipping officer in the logistics unit and attached to
slip the goods sent to the customer.
Bill of lading A document that is prepared for the common carriers that transport the goods to the
customer. The shipping officer in the logistics unit prepares this document.
Shipping notice A document that advises the customer what goods, in what quantity, have been shipped.
The shipping officer in the logistics unit generates this document. Sometimes a copy of the
sales order form acts as the shipping notice.
Sales invoice This document is sent to the customer in respect of the goods that he or she has
purchased and shows the amount of sales. The billing officer in the finance or accounting
unit prepares this document.
Remittance A document that shows the cash receipts from a customer. This document may be
advice prepared by the finance or accounting unit and attached as a stub to the sales invoice. The
customer then returns this stub with the necessary payment to the finance or accounting
unit. The customer may also send a remittance advice informing the finance or accounting
unit of the nature of the payment.
Customer service A document that is used by customer service personnel in the marketing unit to record
log customer enquiries and the necessary actions (if any) undertaken to address the
customer’s queries or concerns.

Strategic implications of the revenue cycle

The revenue cycle is strategically important; the level of sales achieved drives all other activity levels
within the organisation. In order to survive and prosper an organisation must not only remain profit-
able (i.e. revenues must exceed expenses), it must also be able to achieve positive cash flows. A sound,
well-controlled revenue cycle can provide a competitive advantage by delivering superior customer ser-
vice, which in turn can translate to opportunities to sustain higher product pricing. An alternative form
of competitive advantage afforded by a revenue cycle that is efficient and effective is the potential to
control costs. This translates into an opportunity to price goods and services at a level that undercuts the
prices of less efficient competitors and increases market share.
Ideally, with an efficient and effective revenue cycle ensuring superior levels of customer service at
a low cost, both of these competitive advantages would be realised simultaneously; however, in reality,
these goals often prove to be incompatible. The revenue cycle generally offers consumers greater value
either by offering lower prices or by providing benefits and services that justify a higher price. As
discussed in chapter 2, the most important organisational issue is successful alignment of processes,
including the revenue cycle, with the organisation’s strategy, which should overarch and guide all busi-
ness process design. A well-aligned revenue cycle will be congruent with the organisational strategy and
compatible with the organisational goals, mission and culture. AIS Focus 10.1 illustrates the benefits of
aligning business strategy with the revenue cycle.

CHAPTER 10 Transaction cycle — the revenue cycle 429

 AIS FOCUS 10.1

Simply Energy
From headquarters based in Melbourne, Victoria, Simply Energy sells electricity and gas to retail
customers in Victoria and South Australia; managing more than 350  000 domestic and 1500 com-
mercial customer accounts. The process of billing customers involves correctly identifying the
volume of electricity and/or gas each customer has consumed over the preceding time period, then
producing a bill based on the volume consumed and the contract rate applicable to the customer.
Usage data are recorded by means of a meter located at the customer’s premises and collected
periodically by third-party organisations employing meter readers or, increasingly, by means of
automated data feeds obtained from smart meters being rolled out across Australia. Usage data
are stored in a central database shared by electricity and gas providers Australia-wide; relevant
usage data is periodically extracted and uploaded to Simply Energy’s systems for customer billing
purposes.
Simply Energy had identified that some accounts that initially were set up correctly were accessing
out-of-date usage data. In some instances, customers were not being billed at all. With such a large
number of accounts to manage and maintain, Simply Energy was concerned about the effect that inac-
curate data were having on customer service standards, as well as its bottom line. Simply Energy had
no easy and reliable way to reconcile the data and therefore were unable to analyse where errors were
occurring and for what reason.
Brave Energy Systems is a supplier of software and consultancy services to the Australian energy
market. Its Bravo Bill Reconciliation product is a specialised tool used to detect revenue leaks. The tool
was deployed across Simply Energy’s billing systems and highlighted process failures relating to both
the billing cycle and the customer account set-up phase. By undertaking ongoing bill reconciliation,
every aspect of the billing process was analysed, clearly identifying where issues in the billing software
and business process were affecting revenue. Once rectified, customer service staff enjoyed increased
confidence in the accounting process, through using systems tools to check customer queries such
as energy volume billed versus actual volume used (as supplied by the meter readers), knowing that
the data would be accurate. As a result of this proactive identification of errors, customers also ben-
efited from receiving accurate and timely accounts. Most importantly, by understanding where the billing
processes were failing, Simply Energy recovered significant lost revenue. It continues to monitor and
measure its billing system, seeing problems and rectifying them long before they can have an impact
on revenue.
Like any retailer we need to be vigilant in monitoring and fixing revenue leakage. Every time an error or
issue is resolved in one of our billing applications we see a direct impact on our bottom-line. The advan-
tage of the Brave system is that it not only identifies where our processes are failing, but measures the
expected revenue improvements against actual once we have put a fix in place.
Elson Abat, General Manager, Shared Services, Simply Energy
Source: Adapted from Brave Energy Systems, www.braveenergy.com.au.

10.2 Technologies underpinning the

revenue cycle
LEARNING OBJECTIVE 10.2 Evaluate common technologies underpinning the revenue cycle.
There are a number of technologies suitable for supporting activities within the revenue cycle to improve
the overall functioning of the process. A range of data management tools are available to help improve
the organisation’s ability to capture and analyse revenue data. Transparency and management of cash
and cash flow can also be improved by use of appropriate technologies.
Enterprise resource planning (ERP) systems assist with enabling and integrating the revenue cycle.
The revenue cycle links into many areas within the organisation; an ERP system not only improves the
integration of enterprise-wide data but also provides tighter linkages between relevant modules such as
marketing, sales, production, shipping, billing, accounts receivable and general ledger.

430 PART 3 Systems in action

 The revenue cycle can benefit greatly from technologies that provide an efficient means of data
exchange. It is more efficient, timely and cost effective to transact electronically. Much of the paper-
work generated by the revenue cycle (e.g. invoices and shipping documents) originates in-house and
is sent outwards to customers. The ability to transact online not only speeds up the revenue transaction
cycle, it can also act to outsource some of the transactional work, and therefore costs, to the customer.
Technologies such as ­electronic data interchange (EDI) (to produce specifically tailored systems for
large repeat customers) and eXtensible Markup Language (XML) (for online sales sites) help provide
efficient data exchange.
Paper documentation sent into the organisation as part of the revenue cycle (typically remittance
advices and customer purchase orders) can be handled more efficiently using digital imaging. Scanning
documents speeds up processing by providing broader immediate access to incoming documentation.
Improvements in the revenue cycle can be made by undertaking data mining or trend analysis in order
to improve understanding of markets and product performance. Providing some form of revenue data
warehouse is necessary in order to undertake these activities. Revenue data warehouses typically store
summar­ised historical revenue data arranged along product or segment lines, allowing data mining to
take place.
Customer relationship management (CRM) technologies can support revenue cycle activities by
improving understanding of customers and their interactions with the organisation. CRM technologies
typically store historical revenue data arranged by customer, in contrast to data warehouses, which tend
to store data arranged by market segments or chronology.
Online payment facilities such as BPAY provide a simple and cost-effective way for organisations
to receive payments. In addition to providing more timely payments, using customer self-service sys­
tems such as BPAY helps cut data entry costs and reduce error rates. The use of online banking facil-
ities improves transparency and reconciliation of transactions and involves less cash handling, which
improves security and cash flows.
Tracking and recording inventory forms a large part of the sales process. The efficiency and accuracy
of inventory-related activities can be improved by the use of barcode scanners.
Barcode scanning not only reduces error levels by automating data input, it improves timeliness as
scanned data is immediately uploaded and available for use. AIS Focus 10.2 gives an example of how
technology can be used to improve the sales process.

AIS FOCUS 10.2

Caffe Primo chain

Caffe Primo of Adelaide, South Australia, is a group of 20+ café/restaurants that specialises in providing
good-quality meals at value prices. When making plans to expand his restaurant chain in metropolitan
Adelaide and regional South Australia, owner Dino Vettesse knew exactly what type of Point of Sale
Management system he had to have. ‘It absolutely had to be easy to install and learn. We have a lot of
casual staff in this industry, and they need to be able to pick up a new system and become productive
very quickly.’
It also had to provide timely management controls and key performance measurements. ‘Only hard
facts let you run a smooth operation. We need to know accurately what’s selling and not selling, how
one week compares to the next, especially when we make menu changes, and I needed a system
that would give me the reports that would make the facts I need jump out at me from the paper or the
screen.’
When asked about the support provided, Vettesse responded, ‘It’s very good. The system has never
been down for more than a couple of hours since the first day we had it. If we do have a problem, we
get on the phone to the helpdesk and we’re fixed in no time.’
‘We’ve been running the [Redcat point of sale] system for a number of years now,’ Vettesse says,
‘and we think it’s a great system. We could never go back to our old system. The chefs and the floor
staff love it!’1

CHAPTER 10 Transaction cycle — the revenue cycle 431

10.3 Data and decisions in the revenue cycle
LEARNING OBJECTIVE 10.3 Recognise revenue cycle data and key revenue business decisions.
A range of data are both produced and consumed by activities within the revenue cycle. The actual data
stores are documented in detail later in this chapter; this current section describes the general purpose
of the data and the types of data that the revenue cycle requires. The business decisions made during the
life of the revenue cycle are also described here.

Data and the revenue cycle

Revenue cycle activities require access to customer data, which contain details of all existing customers,
in order to identify authorised customers. Customer data is ideally produced by a dedicated customer
management section of the organisation, which has responsibility for identifying and authorising new
and existing customers but is not involved in revenue cycle activities. This customer management sec-
tion would also be responsible for assigning and reviewing customer credit limits. The revenue cycle
uses customer data in several different activities; for example, customer credit data helps to decide if
a customer is creditworthy, customer address data is used to arrange shipment and invoicing of goods,
data relating to customer demographics and order characteristics is often collected during revenue cycle
activities for use in future marketing programs.
An important data source for the revenue cycle is inventory data, which is a record of each item
stocked or regularly ordered. Inventory data is primarily created by activities within the expenditure
cycle; however, the revenue cycle also updates inventory data by recording decreases in stock levels cre-
ated by shipment of goods. Inventory data related to existing stock levels are also accessed by the sales
process when deciding whether there is sufficient inventory for a potential sale to occur.
Accounts receivable data are both created and updated by activities within the revenue cycle; invoices
created by billing activities are recorded in accounts receivable, as are details of payments received
during the accounts receivable process. More detailed information about customer payments is recorded
in the cash receipts data. The most detailed data produced by the revenue cycle are sales data, which
contain all details of each sale made by the organisation and the status of the sale. An additional common
data record is accounts receivable adjustments data, where any bad or doubtful debts and sales returns
are recorded. These data are useful when undertaking analysis of revenue cycle performance, in addition
to forming part of financial reports.

Revenue cycle business decisions

Process business decisions are made at different levels during the life of the revenue cycle. When the
cycle is originally designed, or subsequently reviewed, a number of strategy-level decisions need to be
made. These decisions are typically made by senior management within the organisation and create
the policy framework within which the cycle operates. To be effective, strategy-level business process
decisions should be congruent with the overarching business strategy. Strategy-level decisions would
include creation of policies for areas such as:
•• price setting — requires construction of pricing algorithms, consideration of competitor price points
and an understanding of the degree of market tolerance
•• sales return and warranty policies — involve predicting potential volume of returns, incorporating
any relevant legislation and identifying any product characteristics that make returns more or less
acceptable
•• provision of customer credit facilities — requires consideration of the options available and the costs,
benefits and risks of each of these for the organisation
•• cash collection policies and procedures — require knowledge of average payment times, industry
standards, customer credit policies and legal requirements.

432 PART 3 Systems in action

 In addition to these strategy-level decisions, there is a range of operational level decisions that will
be made every time the revenue cycle is enacted. These operational decisions are typically made by less
senior staff and relate only to a specific instance of the cycle. Typical operational decisions include:
•• responding to customer inquiries such as a request to purchase goods, or to return goods for credit
— requires consideration of the customer’s purchase history and their accounts receivable history, in
addition to knowing the options available under the applicable policy
•• responding to a request to extend credit to a particular customer — requires consideration of the
customer’s prior history and likely sales volume
•• calculating inventory availability — requires knowledge of current levels of stock on hand, stock on
order, stock promised to customers and supplier lead times
•• selecting goods delivery method — requires understanding of policy alternatives available combined
with the costs and risks of the specific transaction being considered
•• determining correct cash receipt allocations for a customer payment — requires access to details of
invoices outstanding and any remittance advice data supplied by the customer.

10.4 Revenue cycle documentation

LEARNING OBJECTIVE 10.4 Summarise and prepare documentation synthesising the primary activities
in the revenue cycle and the data produced by these activities.
The revenue cycle is documented in the following section as a series of diagrams with increasing
amounts of detail. An overview of these revenue cycle diagrams is shown in figure 10.2.

Context diagram Revenue

– figure 10.4 cycle

Level 0
1.0 2.0 3.0 4.0
logical
Process the Pick, pack & Bill the customer Receive and
diagram
sales order ship the goods record payment
– figure 10.5

1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 4.1 4.2
Check Credit Create Pick the Prepare Deliver Check sales Create Receive Record
inventory check sales order goods for shipping the goods completion invoice payment payment
levels

Level 1 logical diagram – figure 10.10 Level 1 logical diagram – figure 10.14 Level 1 logical diagram Level 1 logical diagram
Process 1.0 process map – figure 10.11 Process 2.0 process map – figure 10.15 – figure 10.22 – figure 10.22
Physical DFD – figure 10.25 Process 3.0 process map Process 4.0 process map
Flowchart – figure 10.26 – figure 10.23 – figure 10.23

FIGURE 10.2 Revenue diagrams overview

Revenue cycle context

The context diagram of a typical revenue cycle is depicted in figure 10.3. The revenue cycle involves
direct interaction with entities outside the organisation such as customers, couriers and banks. Within the
organisation, the revenue cycle interacts with the production, HR management and payroll, and general
ledger and financial cycles as shown in figure P3.1. Details of the logical data flows depicted in the
­revenue context diagram are contained in table 10.2.

CHAPTER 10 Transaction cycle — the revenue cycle 433

 Customer

(43)
(17)

(1) (44)
(39)

(5) Production
Revenue cycle
(23)
cycle
(26)

HR cycle
(46) (33)
(50)

Bank
Courier
Financial
cycle

FIGURE 10.3 Revenue cycle context diagram

Revenue cycle logical data flows

Figure 10.4 depicts a level 0 logical DFD. This diagram shows the entire revenue cycle in greater detail
than that depicted in the context diagram.
The logical DFD is an exploded version of the context diagram, with the bubble described
as ‘revenue cycle’ in the context diagram broken down into four processes. The logical diagram at
level 0 helps to analyse and understand the revenue cycle in its entirety. It depicts the chronology
of the cycle, the data stores and external entities involved in each of the processes, and the inter-
actions between these processes, entities and data stores. The logical level 0 diagram in figure 10.4
is itself broken down to describe even lower levels of detail in figures 10.9, 10.13, 10.18 and 10.21
later in this chapter. Details of the logical data flows depicted in this diagram are contained in
table 10.2.

Description of logical data flows in the revenue cycle

A logical DFD contains only those data flows relating to inputs and outputs of the activities contained
within each of the processes, as opposed to the details of all interactions between entities which are
depicted in a physical DFD. As a result, the number of flows in a logical DFD is always less than those
that would be shown in a physical DFD for the same process. To illustrate this, compare figures 10.9 and
10.24, which both show exactly the same process; however, figure 10.9 is a logical description whereas
figure 10.24 is a physical depiction. To ensure completeness, all the data flows relating to the revenue
cycle appear in table 10.2.

434 PART 3 Systems in action

 Accounts HR cycle
receivable
Customer
(9)
(1) (10)
(23)
(14)
1.0
(17) Sales
Process
the sales (19)
order
(5)
(22)
(3)
(16) (8)

Production (24)
cycle Customers
Inventory

(30)
(27)

(25) (26) 2.0

Pick, pack
(31) (34)
and ship the
goods (28)
2.1 – 2.3
Shipping (33) Sales
(35)

Courier (37)

(38)

3.0
Bill the
customer
(40)

Accounts
(39)
receivable

(41)
Customer (43) (48)

(49)
(44)
4.0
Receive and
Customers
record
(45)
payment
(42)

(46) (50)
Cash receipts

Financial
Bank
cycle

FIGURE 10.4 Revenue cycle level 0 logical diagram

CHAPTER 10 Transaction cycle — the revenue cycle 435

TABLE 10.2 Description of logical data flows in the revenue cycle

Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

Process 1.0 Process the sales order

1 Customer Sales officer Details of the goods The customer contacts the sales officer to
the customer wants request the goods.
to purchase

2 This flow takes place physically between the sales officer and the computer; it happens within the 1.0 bubble in the
logical diagram.

3 Inventory data Sales officer The level of stock on The level of stock for any products the customer
store hand for requested wishes to buy is checked. This ensures that the
products customer is not promised goods that cannot
be delivered, or alternatively that a sale is
erroneously rejected.

4 This flow takes places physically between the sales officer and the computer; it happens within the 1.0 bubble in the
logical diagram.

5 Sales officer Production cycle Details of goods If the company manufactures its products
required to be in-house, and there is insufficient finished goods
produced inventory available to fill the sales order, the sales
officer will notify the production cycle of the
demand for the goods.

6 Inventory check Credit check Trigger for next After the inventory check has been completed
process the credit check process can commence (not
necessary in a level 0 diagram).

7 This flow takes place physically between the sales officer and the computer; it happens within the 1.0 bubble in the
logical diagram.

8 Customer data Sales officer The customer’s credit The sales officer should ensure that the customer
store limit is creditworthy before the sale is processed. If
no credit limit exists, or the credit is insufficient
to cover the requested purchase, the sale should
not proceed.

9 Accounts Sales officer Current accounts The sales officer can determine whether there
receivable receivable balance is sufficient credit available by comparing the
data store for the customer current amount of credit currently being used to
the credit limit for the customer. If the remaining
credit is insufficient to cover the requested
purchase, the sale should not proceed.

10 Sales order data Sales officer Recent sales to the The sales event data will contain detail of any
store customer recent sales that may not yet have been updated
into the accounts receivable data store. The value
of any recent sales should be deducted from the
remaining credit available for the customer; if the
requested purchase exceeds this amount the sale
should not proceed.

11 This flow takes place physically between the sales officer and the computer; it happens within the 1.0 bubble in the
logical diagram.

436 PART 3 Systems in action

 Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

12 Credit check Sales order Trigger for next After the credit check is complete, the create
creation process sales order process can commence (not
necessary in a level 0 diagram).

13 This flow takes place physically between the sales officer and the computer; it happens within the 1.0 bubble in the
logical diagram.

14 Sales order Sales order data Sales order details This data flow represents the action of updating
officer/customer store of the sales order data with the newly created
sales order. Only orders that have inventory
available and a sufficient customer credit limit will
be created.

15 This flow takes place physically between the sales officer and the computer; it happens within the 1.0 bubble in the
logical diagram.

16 Sales order data Inventory data Details of inventory The items listed on the sales order are used to
store store items in sales order update the inventory data. The inventory item
status is typically marked as ‘promised’ for any
items included on the sales order, and the goods
available balance is reduced by the quantity of
these items.

17 Sales officer Customer Sales order The sales officer should advise the customer
confirmation whether or not the sale will proceed.

18 This flow takes place physically between the sales manager officer and the computer; it happens within the
1.0 bubble in the logical diagram.

19 Sales order data Sales manager Commissions Identification of sales on which commissions are
store payable payable, and calculation of commission amounts
that are going to be paid.

20; 21 These flows take place physically between the sales manager officer and the computer; they happen within the
1.0 bubble in the logical diagram.

22 Sales manager Sales order data Approved sales order Once the sales manager has approved the
store details commission amounts proposed, the sales order
record is updated to indicate a commission
payment has been approved for the sale.

23 Sales manager HR cycle Approved sales order This flow would take place where sales people have
details a commission component included in their salary.

24 Sales officer Picking officer Sales order details This flow alerts the picking officer in the
warehouse that a sales order has been
processed, and advises which goods need to be
packed for the sales order.

25 Sales officer Billing officer Sales order details When a sales order is created, the billing section
needs to receive notification that the sale has
occurred.

(continued)

CHAPTER 10 Transaction cycle — the revenue cycle 437

TABLE 10.2 (continued)

Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

Process 2.0 Pick, pack and ship the goods

26 Production cycle Warehouse staff Finished goods When the production cycle has completed the
available notification manufacture of the goods requested, warehouse
staff are advised of goods availability.

27 Picking officer Inventory data Sales order status The inventory status for the relevant items is
store updated to ‘picked’.

28 Picking officer Sales order data Sales order status The sales order status is updated to ‘picked’.
store

29 Picking the goods Delivering the Trigger for next After the goods are picked the delivery process
goods process can commence (not necessary in a level 0
diagram).

30 Customer data Shipping officer Customer delivery The customer delivery details are combined with
store details the picking ticket and used to produce a shipping
label.

31 Shipping officer Shipping data Shipment details Shipment details are stored in the shipping data
store store.

32 Preparing for Delivering the Trigger for next After the goods have been packed and labelled,
shipping goods process the delivery process can commence (not
necessary in a level 0 diagram).

33 Shipping officer Courier driver Delivery details The goods and shipping details are given to the
courier for delivery to the customer.

34 Shipping officer Sales order data Sales order status The sales order status is updated to ‘shipped’.
store

35 Shipping officer Billing officer Sales order and The data flow advises the billing officer that
shipment details a sales order has been completed and goods
despatched, and requests that an invoice be
raised.

Process 3.0 Bill the customer

36 Checking Creating the Trigger for next Once the billing officer has checked that goods
completed sales invoice process have been despatched in accordance with the
sales order, the invoice can be created (not
necessary in a level 0 diagram).

37 Sales data store Billing officer Sales details Details of the unbilled sale are extracted from the
sales data store and used to create the invoice.

38 Billing officer Sales data store Sales order status The sales order status is updated to ‘billed’.

39 Billing officer Customer Invoice details The invoice details are sent to the customer,
either electronically or on paper.

40 Billing officer Accounts Invoice details The invoice details are posted to the customer’s
receivable data account in the accounts receivable data store.
store

438 PART 3 Systems in action

 Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

Process 4.0 Receive and record payment

41 Accounts Accounts Invoice and cash Details of unpaid invoices and payments
receivable data receivable officer receipts details receipted since the last statement was issued are
store extracted from the accounts receivable data store
for use in preparing the customer’s statement.

42 Customer data Accounts Customer details Customer details such as name and address are
store receivable officer added to the accounts receivable data for use in
preparing the customer’s statement.

43 Accounts Customer Statement details The statement of account is sent to the customer,
receivable officer either electronically or on paper.

44 Customer Cashier Payment details The customer sends payment and an

accompanying remittance advice to the cashier.

45 Cashier Cash receipts data Cash receipt details The cashier receipts the payment and the data is
store saved into the cash receipts data store.

46 Cashier Bank Cash receipt details Cheques and related cash receipts data are taken
to the bank to be deposited into the company
bank account.

47 Receiving Recording Trigger for next Once the payment has been receipted and
payment payment process banked, the payment can be recorded against
the customer’s accounts receivable account (not
necessary in a level 0 diagram).

48 Accounts Accounts Unpaid invoice The accounts receivable officer extracts details of
receivable officer receivable data details unpaid invoices to help determine how to allocate
store the payment received to the customer’s accounts
receivable account.

49 Accounts Accounts Cash receipt details The payment received is allocated to unpaid
receivable data receivable officer invoices in the customer’s account in the
store accounts receivable. Invoices for which payments
have now been received are updated with a
status of ‘paid’.

50 Accounts Financial cycle Invoice and cash The data relating to the invoices raised and
receivable officer receipt details payments received, which is contained in the
accounts receivable data store, is transferred to
the financial cycle, where it is used to update
general ledger accounts.

10.5 Revenue cycle activities and related

risks and controls
LEARNING OBJECTIVE 10.5 Assess risks and compose control plans pertinent to the primary activities
in the revenue cycle.
The activities within the revenue cycle and the associated risks and controls are now described under the four
revenue process headings. Following the activity descriptions for each of the processes is the process map
and level 1 DFD for the process and a table summarising the activities, risks and controls within the process.

CHAPTER 10 Transaction cycle — the revenue cycle 439

Process the sales order — activities, risks and controls
Process 1.0, process the sales order, comprises the following activities.

Check inventory levels

The revenue cycle starts when a customer contacts the organisation wanting to purchase some goods.
This request could be made electronically, either as an email or an online order placed through a web-
site, or on paper as a letter or form (purchase order) completed by the customer and posted to the organ-
isation. In the case of traditional retail sales, the customer usually selects the goods they require from an
open display and presents them directly to the cashier with their payment.# After a customer makes their
request for goods, the level of stock for the products the customer wishes to buy is checked; this ensures
that the customer is not promised goods that cannot be delivered, or that a potential sale is erroneously
rejected when stock is actually available. Figure 10.5 contains an example of an inventory status report
used to support this decision.

L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Reports >

Inventory Item List

Today 20 Jul 2015 Update Report Settings

Inventory Item List

L & E bicycles
As at 20 July 2015

Item Code Item Name Inventory Type Unit Cost Price Unit Sale Price Average Cost Total Value Quantity On Hand

630 - Inventory
BMX Mongoose BMX Tracked 216.00 280.00 196.36 18,850.65 96

Hybrid Giant B2015 Hybrid Tracked 1,200.00 1,570.00 1,090.91 19,636.36 18

Road Samson Road Bike Tracked 430.00 565.00 390.91 27,363.64 70

Tour Aiteo2 Tour Bike Tracked 600.00 780.00 - - 0

Mountain Mongoose 2015 Mountain Tracked 600.00 780.00 545.45 8,727.27 16

Bike

Total 630 - Inventory 74,577.92 200

Total 74,577.92 200

FIGURE 10.5 Inventory status report

Source: © Xero Limited.

# In order to display the depth and complexity of the revenue process, this very simple retail sales process is not
documented in this chapter. The process documented assumes that a customer places an order for goods which need
to be packed and despatched, and that the customer is billed and makes payment subsequent to delivery.

440 PART 3 Systems in action

 If the company manufactures its products in-house, and there is insufficient finished goods inventory
available to fill the sales order, the production cycle would need to be notified of the demand for the
unavailable goods so they can be manufactured. A common risk is the potential for individuals to create
fictitious sales. Controls to reduce this risk include requesting a signed purchase order form from the
customer prior to accepting a sale, and confirming customer accounts regularly by sending statements
of account.
One risk of the revenue cycle is promising goods to a customer that are not available to be shipped;
in order to avoid this risk, an inventory check should always be performed before accepting a sale. An
additional related risk is that of poor decision making, which could result in deciding to allow an order
to proceed when goods are not available, or rejecting an order when goods are available. To reduce the
risk of poor decisions it is important to maintain accurate and timely perpetual inventory records and
periodically conduct physical inventory checks. Accurate timely data will support more accurate decision
making. The controls suggested act to ensure that the stock levels recorded and used for decision making
are accurate and timely.

Credit check
The sales officer should also ensure that the customer is creditworthy before the sale is processed.
A credit check requires three separate pieces of information. The first piece of information identifies
if a credit limit has been established for the customer. Figure 10.6 shows an example of a credit appli-
cation form. If no credit limit exists, the sale should not proceed. The second piece of information is
whether there is sufficient credit available; this information is obtained by comparing the amount of
credit currently used (i.e. the amount the customer currently owes the organisation) to the credit limit
for the customer. If the remaining credit is not enough to cover the requested purchase, the sale should
not proceed. The final piece of information is the detail of any recent sales that may not yet have
been updated into the customer’s accounts receivable account. The value of any recent sales should be
deducted from the remaining credit available for the customer; if the requested purchase exceeds this
amount, the sale should not proceed.
The credit check is undertaken to ensure that the organisation does not sell goods to a customer who
won’t or can’t pay for the goods and is an important control. There is a risk of poor decision making
attached to this activity, either by accepting an uncreditworthy customer, or incorrectly rejecting a
creditworthy customer. To reduce this risk it is important to independently maintain customer accounts
and credit limits. The ability to add a new customer and change or assign a credit limit should not
be devolved to staff in the sales area; this helps avoid situations where credit limits are established based
on desired sales targets, rather than on the fiscal soundness of the customer.
To remove the risk of non-payment altogether the organisation may wish to consider the use of
a pre-billing system. Pre-billing systems require payment before the goods are despatched and are
almost universal in online sales environments. Pre-billing systems are in contrast to post-billing
systems where the customer is billed for the goods after the goods are dispatched. Additional useful
controls for the risk of selling to uncreditworthy customers include producing regular exception
reports listing any sales rejected, and regularly monitoring accounts receivable balances and the age
of all receivables. These controls also provide a post-hoc analysis of the effectiveness of customer
credit decision making.

CHAPTER 10 Transaction cycle — the revenue cycle 441

 Australian Information Company
Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Credit application form No: 1002919

Please complete the required details below ensuring that all information supplied is true to the best of your
knowledge. Please circle where appropriate.

Personal details

Your full name: Title: Ms/Mr.

Your home address: Your postal address (if different from home address):

Credit history

Status of home: renting/boarding/own home/other How long have you been there?
(please specify): Years      Months

State details of your assets (e.g. car, furniture, equipment etc.)

Description: Approximate value:
Description: Approximate value:
Description: Approximate value:
Description: Approximate value:

State your credit card details here:

Issuer: Card no.: Credit limit:
Issuer: Card no.: Credit limit:
Issuer: Card no.: Credit limit:
Issuer: Card no.: Credit limit:

Other liabilities:
Description: Amount owing:

Total monthly expenses (to the nearest dollar):

Please sign the declaration below:

The above details are correct and true to the best of my knowledge. I hereby authorise Australian Information
Company to supply my credit details to credit agencies to verify my creditworthiness.

Signed:                  Date:

FIGURE 10.6 Sample credit application form

442 PART 3 Systems in action

Create sales order
After the sales request has been checked and the inventory and credit levels confirmed the sales order can be
processed. Any time delay between deciding to accept the sales order and inputting the data related to that
sales order increases the potential for a sale to be lost or forgotten. A risk of failure to process a valid sales
request exists here. To reduce this risk it is important to enter sales data physically close to when the order
request was received and to enter all sales data in a timely manner. A sales order can be produced either man-
ually or by computer; a computerised environment would be used in all but the smallest of businesses.
The creation of the sales order is accomplished by inputting all the details relating to the customer and the
products, and then generating a sequentially numbered sales order. Only orders that have inventory available
and a sufficient customer credit limit should be created. The sales order should ideally be created as soon
as each sales transaction is processed, but it could also occur as a batch process at regular predetermined
intervals. The sales order is a document that is internal to the organisation. It may never be necessary for it
to be produced in paper form; its primary purpose is to notify two different areas of the new sale. Generating
a new sales order notifies the warehouse that goods need to be packed and despatched to the customer, and
notifies the accounts area that a sale has been accepted. An example sales order is shown in figure 10.7. The
sales order forms the basis for subsequent billing of the customer. The actual billing of the customer can
occur prior to goods despatch, but more often occurs after (or simultaneously with) the customer receiving
the goods. In addition to triggering these workflows, the items listed on the sales order are used to update
the inventory data. The inventory item status is typically marked as ‘promised’ for any items included on
the sales order, and the goods available balance is reduced by the quantity of these items. This ensures that
future inventory balance checks take account of items promised to a customer, but not yet picked or shipped,
helping to ensure that decisions relating to stock availability are accurately supported.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Sales order form No: SO-1245

To: Ms Margaret Sinu (Customer ref.: 672839)

1/56 Mount Waverley Road Perth 6523

Entered by: Approved by:

Mike Myers, Sales Department Zincal Sion, Sales Manager

Order date: Customer order no.:

01/04/15 Int-029389

Delivery speed: Shipping via: Payment method:

Normal Calmex Logistics Invoice customer

Remarks: NIL

Item no. Description Quantity

78293 Gigante CD-ROM 1

82838 Picole light pen 5

53564 Sanman computer pen 5 boxes

FIGURE 10.7 Sample sales order form

CHAPTER 10 Transaction cycle — the revenue cycle 443

 The customer should be advised whether or not the sale will proceed; this acknowledgement can
take the form of a copy of the sales order sent to the customer in either electronic or paper form, as
shown in figure 10.8. If the sale is not able to proceed due to inventory being unavailable, the cus-
tomer should be advised of possible product alternatives if any are available, or offered the oppor-
tunity to have the product placed on back order for later delivery. If the order is not proceeding
due to a credit limit problem, the customer should be advised of the reason and given a contact if
they wish to discuss this further. Note that the sales officer should not be able to update the credit
limit for a customer. If a credit limit is to be renegotiated, this would normally be undertaken by a
separate customer finance approval division. The risks related to this activity include an incorrect
decision outcome being advised to the customer, or a customer not being advised of the outcome at
all. Controls to reduce these risks include automating the sales order creation process using a pre­
devised workflow, or exception reporting identifying any customer orders received but not acknowl-
edged within a reasonable timeframe.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Order acknowledgement form No: C12-2004

To: Ms Margaret Sinu (Customer ref.: 672839)

1/56 Mount Waverley Road Perth 6523

Date order received: Entered by:

01/04/15 Mike Myers, Sales Department

Order summary
Please carefully check the order details below and contact the sales department if any details
shown are incorrect.

Item no. Description Quantity Price/unit

78293 Gigante CD-ROM 1 $250.00

82838 Picole light pen 5 $ 60.00

53564 Sanman computer pen 5 boxes $  9.00

FIGURE 10.8 Sample order acknowledgement form

Once the sales order has been created, it is also possible to identify sales on which commissions are
payable and calculate commission amounts payable. This activity takes place only where sales staff
have a commission component included in their salary. Details of sales used for commission purposes
should be prepared, or at least approved, by someone other than the sales staff involved. Note this
activity may alternatively be conducted as part of the HR management and payroll cycle depending on
the organisation’s policy regarding commission payments. There are several alternatives for paying sales
commissions: some organisations withhold payment of sales commissions until the goods have been
delivered, others wait until goods have been paid for, and still other organisations impose a quota system
with sales commission being calculated monthly or quarterly based on meeting sales targets. There is
a risk that an incorrect sales amount will be advised, resulting in under/overpayment of commissions
to sales staff. Automatic calculation of commissions payable based on sales order data, and requiring
independent authorisation before commissions can be paid, are controls that reduce this risk.

444 PART 3 Systems in action

Process the sales order — DFD and process map
The level 1 DFD in figure 10.9 contains a lower level of detail about the first process represented in the
level 0 logical DFD in figure 10.4. In the same way in which the level 0 logical diagram explodes out
the ‘revenue cycle’ bubble in the context diagram, the level 1 diagram explodes out the ‘process the sales
order’ bubble.

Production
(5) cycle
Customer

(1)

1.1
Check
inventory
levels
Customers

(8)
Accounts
(6) receivable
(3)

(9)

1.2
Inventory Credit check (10)

(17) Sales
(12)

(14)
(16)
(19)

(22)

1.3
Create sales
order
(23)

HR cycle (25)
(24)

2.0
3.0
Pick, pack
Bill the
and
customer
ship goods

FIGURE 10.9 Revenue cycle level 1 logical diagram — process 1.0 Process the sales order

CHAPTER 10 Transaction cycle — the revenue cycle 445

 Summary description of activities in processing the sales order
Table 10.3 summarises the activities, risks and controls when processing a sales order, as depicted in
figures 10.9 and 10.10. Table 10.2 explains the logical data flows depicted in figures 10.9 (Level 1 log-
ical DFD) and 10.10 (Process map). Exploring the diagram in conjunction with the material contained in
the tables will assist in improving your understanding of the process depicted.

Creates sales
Computer Displays stock Displays credit order and
levels available updates
inventory

Sales officer Requests stock Stock Requests credit Sufficient Advises

levels available? availability credit? customer

Sales
Sales manager commission
payable?

Customer Order status

Requests goods
advice

Receives advice
HR cycle commission is
payable

Picking officer Receives request

to pick goods

FIGURE 10.10 Revenue cycle process map — process 1.0 Process the sales order

446 PART 3 Systems in action

TABLE 10.3 Activities in processing the sales order

Usually
Activity # Activity conducted by Activity description Typical risks encountered Common controls

1.1 Check Sales officer Decide if sufficient Selling goods that are not Performing inventory checks
inventory stock is available available to be shipped
levels to proceed with the
order by comparing Poor decision making — Maintaining accurate and timely
the goods available allowing an order to perpetual inventory records,
to the goods proceed when goods are periodically conducting physical
requested by the not available, or rejecting inventory checks
customer. an order when goods are Exception reporting for
available management of any sales
rejected

1.2 Credit Sales officer / Decide if customer Selling goods to a Performing inventory check
check sales manager is creditworthy and customer who won’t/ can’t (see example in figure 10.11)
whether the sale pay for the goods Independent maintenance of
should proceed customer accounts and credit
by determining limits, pre-billing systems
currently available
credit capacity. Poor decision Exception reporting for
making, accepting an management of any sales
uncreditworthy customer, rejected
or rejecting a creditworthy Regular monitoring of accounts
customer receivable balances and age

1.3 Create Sales officer / Input data, create Creating fictitious sales Signed purchase order form
sales sales manager the sales order and from customer
order update sales data. Confirming customer accounts
Once order is regularly via statements of
created, advise account
the customer of
Failure to process valid Entering data physically close
the sales order
sales request received to when order request is
outcome.
from customer received
Advise HR of Entering data in a
any commissions timely manner
payable if
applicable. Incorrect decision Automation via pre-devised
Advise warehouse outcome advised workflow
picking officer of
Customer not advised of Exception reporting of customer
goods required, and
outcome orders not acknowledged within
advise billing that
a reasonable timeframe
the sales order has
been created. Incorrect sales advised, Automation using sales order
resulting in under/ data
overpayment of Obtaining approval from sales
commissions to sales staff manager before commissions
are paid

Incorrect goods included Automation using sales order

on picking ticket data

Warehouse not advised Automation using sales order

of the picking ticket details data
Exception reporting of sales
orders with no picking tickets
generated

CHAPTER 10 Transaction cycle — the revenue cycle 447

 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Sales › Invoices ›
New Invoice

To Date Due Date Invoice # Reference

Fixie Co 20 Jul 2015 7 Jul 2015 INV-0005

Currency AUD Australian Dollar Amounts are Tax Inclusive

Item Description Qty Unit Price Disc% Account Tax Rate Amount AUD
Mountain: Mongoose 2015 Mountain Bike 15.0000 780.00 200 - Sales GST on Income 11,700.00
Mongoose 2015
Mountain Bike 14 on hand

Subtotal 11,700.00
Add a new line
Includes GST 10.00% 1,063.64

TOTAL 11,700.00

FIGURE 10.11 Internal control — inventory status check

Source: © Xero Limited.

Pick, pack and ship the goods — activities, risks

and controls
Process 2.0, pick, pack and ship the goods, comprises the following activities.

Pick the goods

When the warehouse receives a new sales order they need to pick and pack the requested goods. Some
organisations create a new document from the sales order data called a picking ticket. Creating picking
tickets is typically fully automated, often as a batch job, with picking tickets being created and printed
out in a warehouse on a daily basis. A picking ticket identifies the sales order number, but not necess-
arily the customer details, and lists all the items required to be assembled to fill the order. For larger
warehouses the picking ticket may include references to the rows or bays in which the required stock is
held. Very large warehouses employ automated stock picking, where the electronic details from the sales
order trigger a robot arm to select and group the required items.
Once the required items have been assembled, the order should be checked and the sales order or
picking ticket updated to indicate that the picking activity has been successfully completed. This acts
to trigger the next set of activities: packing and despatching the order to the customer and ensuring
that the inventory status for the relevant items is updated to ‘picked’. Recording the current status of
inventory is vital; if the status is not updated as each activity is completed, data related to inventory
availability will be unreliable and the inventory availability check discussed earlier will be invalid.
A risk related to picking goods is that of having the incorrect goods included on the picking ticket.
Automatic generation of the picking ticket data directly based on the sales order data will act to
reduce this risk. In addition to receiving incorrect picking tickets, the warehouse may not be advised
in a timely and correct manner of the new picking ticket details. Automatically creating the picking
ticket using sales order data and exception reporting identifying any sales orders with no picking
tickets generated will help detect and reduce this risk. When picking the goods there is risk that

448 PART 3 Systems in action

incorrect goods will be selected. In order to reduce this risk, checking picked goods against the
picking ticket by an independent staff member before the goods are packed is often required. In any
activity involving inventory movement there is always a risk of theft of the inventory. Common con-
trols include restricting warehouse access and conducting random periodic physical stocktakes to
verify stock levels. The risk of theft is directly related to the desirability and portability of the inven-
tory items carried — the controls in place should reflect these dimensions. For example, appropriate
controls would be different for a warehouse full of grand pianos compared to a warehouse full of
laptop computers.

Prepare for shipping

Once the goods have been assembled and checked they need to be packed for despatch. In larger
organisations a shipping area generally receives the goods and the picking ticket from the warehouse
and packs them to be sent to the customer. An example packing slip is shown in figure 10.12. Ideally,
checking and packing the goods would be performed by a staff member not responsible for picking
the goods, as this provides an opportunity for an independent check of the goods prior to despatch.
In smaller organisations one division or person may be responsible for the entire span of activities
involving picking, packing and despatching of goods. In these organisations the controls in place
should reflect the risks posed by the lack of segregation of duties. Risks related to packing include
goods being packed incorrectly (i.e. the wrong goods packed together). Common controls include
enforcing an independent check of the packed goods back to the original picking ticket or automation
in the form of barcode scanners to check the goods. Barcode scanning systems used to handle inven-
tory movement act not only to improve data accuracy, they also improve data timeliness as inven-
tory movement is tracked and captured in real time and the status of inventory items can be updated
immediately.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

To: Ms Margaret Sinu (Customer ref.: 672839)

1/56 Mount Waverley Road
Perth 6523

Packing slip no.: Delivery date: Sales order no.:

P04-1292 15/04/15 SO-1245

Item no. Description Quantity

78293 Gigante CD-ROM 1

82838 Picole light pen 5

53564 Sanman computer pen 5 boxes

Remarks:

FIGURE 10.12 Sample goods packing slip

CHAPTER 10 Transaction cycle — the revenue cycle 449

Deliver the goods
When despatching the goods to the customer a shipping label containing the details necessary for the
goods to be delivered is required. This could be a handwritten form taken from a book supplied by the
courier company, or a computer-generated label based on the data contained in the sales order. Customer
delivery details are combined with the picking ticket/sales order data and used to produce a shipping
label. Note that often customers will have different shipping and billing addresses so the customer data
used to create the sales order will not necessarily be appropriate for shipping purposes. Goods may be
despatched using an employee of the firm, or an external courier company may be contracted to per-
form deliveries. In either case there should be a final check conducted before the goods and shipping
label are handed over to the delivery driver. Once the goods are handed to the delivery driver, the status
of the sales order should be updated to ‘shipped’ to indicate that the goods are on their way. Updating
the status of sales orders is important as it allows accurate information to be provided in response to
customer enquiries. If a customer queries an order delivery time, the status code will show the current
status of the order, so a customer can be accurately advised whether the order has been picked, packed
and shipped, and the likely delivery date.
To reduce the risk of goods being labelled incorrectly it is important to firmly attach shipping labels
to the goods immediately after packing them and possibly include an independent three-way check of
the goods to the picking ticket and the shipping label prior to despatch. Other risks related to the des-
patch of goods include slow delivery or non-shipment of the goods. To reduce these risks an exception
report that identifies goods picked for a sales order but not shipped within a reasonable timeframe is
helpful. Common controls to reduce risks related to the theft of goods include requiring an independent
shipping authorisation check and restricting access to packed goods waiting to be collected for delivery.
The actual delivery of the goods involves several risks; for example, the goods may be delivered incor-
rectly, or may be stolen along the way. The level of risk encountered differs, depending on whether the
delivery is undertaken by a company employee or a contract delivery service. The controls in place
should reflect the degree and type of risk involved, and should include separate and clear packaging and
labelling of each order, and requiring the delivery driver to provide a valid customer signature for each
delivery made.

Pick, pack and ship the goods — DFD

The level 1 DFD in figure 10.13 and the process map in figure 10.14 contain a lower level of detail about
the second process represented in the level 0 logical DFD in figure 10.4. This process takes place after
the sales order has been approved and created in the preceding process and prior to the customer being
billed in process 3.0.

Summary description of activities in picking, packing and shipping

the goods
Table 10.4 summarises the activities, risks and controls when preparing and despatching the goods, as
depicted in figures 10.13 (level 1 logical DFD) and 10.14 (process map). Table 10.2 explains the logical
data flows depicted in figures 10.13 and 10.14. Exploring the diagram in conjunction with the material
contained in the tables will assist in improving your understanding of the process depicted.

Bill the customer — activities, risks and controls

Process 3.0, bill the customer, comprises the following activities.
Check sales completion
Once the sales order has been completed and the goods despatched, an invoice can be raised. Before
commencing the billing activities it is important to check that there is a matching shipping label for each
sales order. Only after the sale has been recorded and the goods shipped is it permitted to bill the cus-
tomer for the goods.

450 PART 3 Systems in action

 1.0
Process the
sales order

Production
cycle
(24)

(26)
Inventory
2.1
Pick the
goods

(27)

(28)
(29) Customer

(30)

2.2
Prepare for
Sales (31)
shipping

Shipping

(32)

(34)

2.3
Deliver the (33)
goods

Courier

(35)

3.0
Bill the
customer

FIGURE 10.13 Revenue cycle level 1 logical diagram — process 2.0 Pick, pack and ship the goods

CHAPTER 10 Transaction cycle — the revenue cycle 451

 Updates sales Updates sales
Produce
Computer order status to order status to
shipping label
‘Picked’ ‘Shipped’

Picking officer Picks goods

Shipping officer Ships goods

Receives
Billing officer updated sales
order

FIGURE 10.14 Revenue cycle process map — process 2.0 Pick, pack and ship the goods

TABLE 10.4 Activities in picking, packing and shipping the goods

Usually
Activity # Activity conducted by: Activity description Typical risks encountered Common controls
2.1 Pick the Picking officer When the picking Picking the wrong goods Checking goods against picking
goods officer receives a ticket by an independent staff
picking ticket they go member
into the warehouse Theft of inventory Restricting warehouse access
and pick up the Conducting random periodic
goods required for the physical stocktakes
sales order.
2.2 Prepare Shipping officer The shipping officer Goods packed incorrectly Independent checking of
for receives the goods packed goods to picking ticket
shipping and the picking Using barcode scanners to
ticket from the check goods
warehouse and
Goods labelled incorrectly Firmly attaching shipping label
packs them.
to goods after packing
A shipping label is
Independent checking of goods to
created and, after
picking ticket and shipping label
undergoing a final
check, the goods Slow/non-shipment of Exception reporting of goods
and shipping label goods picked but not shipped within a
are handed over to reasonable timeframe
the delivery driver. Theft of goods Independent shipping
authorisation check
Restricted access to packed goods
waiting to be delivered
2.3 Deliver Delivery staff/ The goods are Goods delivered incorrectly Separate and clear packaging
the goods courier delivered to the and labelling of each order
customer. Theft of goods Requiring delivery driver to
provide valid customer signature
for each delivery made

452 PART 3 Systems in action

Create invoice
The billing system creates an invoice (an example is shown in figure 10.15) for each valid sale,
based on data from the sales order and the customer data. Ideally, this activity would be fully auto-
mated and run as a batch job once a day, or as appropriate based on volume. At this stage the sales
order status should be updated to ‘billed’. Figure 10.16 displays a report showing billed but unpaid
sales orders and figure 10.17 shows a paid sales order. Changing the status code in this way helps
prevent a sales order being billed twice. The newly created invoice details are posted to the cus-
tomer’s account in the accounts receivable data store in order to record the amounts owing by the
customer.
Updating accounts receivable may happen in real time as the transaction is invoiced, but more com-
monly occurs as a batch job usually run at the end of each day. If invoices are not posted regularly the
amounts showing as owing in accounts receivable accounts will be understated, invalidating the credit
check control discussed earlier. Details of invoices raised also need to be sent to the customer, either
electronically or on paper. Depending on billing and credit policies this invoice may be despatched with
the goods or after the goods are delivered. Alternatively, a pre-billing system may be employed where
payment is required before the goods are despatched, in which case the invoice would be created much
earlier in the revenue cycle.

Sales › Invoices ›

Invoice INV-0002

Awaiting Payment ? Email Print PDF Invoice Options

To Date Due Date Invoice # Total

Bike Therapy 4 Jun 2015 11 Jun 2015 INV-0002 19,100.00
25 Leveson St
NORTH MELBOURNE VIC 3051
AUSTRALIA
Edit address

Amounts are Tax Exclusive

Item Code Description Quantity Unit Price Disc % Accont Tax Rate Amount AUD

BMX Mongoose BMX Bike 20.00 254.55 Sales GST on Income 5,090.91

Hybrid Giant B2015 Hybrid 5.00 1,427.27 Sales GST on Income 7,136.36

Road Samson Road Bike 10.00 513.64 Sales GST on Income 5,136.36

Subtotal 17,363.63

Total GST 10% 1,736.37

TOTAL 19,100.00

Receive a payment ?
Amount Paid Date Paid Paid To Reference
19100.00 Add Payment

History & Notes ?

Approved by alison parkes on 20 Jul 2015 at 17.33 p.m.

INV-002 to Bike Therapy for 19,100.00.

Show History (2 entries) Add Note / Expected Payment date

FIGURE 10.15 (A) Sales invoice as viewed online

Source: © Xero Limited.

CHAPTER 10 Transaction cycle — the revenue cycle 453

 TAX INVOICE
Invoice Date L & E bicycles
4 Jun 2015 985 Nicholson St

Invoice Number FITZROY NORTH VIC 3068

Bike Therapy INV-0002 AUSTRALIA
25 Leveson St
NORTH MELBOURNE VIC 3051
AUSTRALIA

Description Quantity Unit Price GST Amount AUD

Mongoose BMX Bike 20.00 254.55 10% 5,090.91

Giant B2015 Hybrid 5.00 1,427.27 10% 7,136.36

Samson Road Bike 10.00 513.64 10% 5,136.36

Subtotal 17,363.63

TOTAL GST 10% 1,736.37

TOTAL AUD 19,100.00

Due Date: 11 Jun 2015

PAYMENT ADVICE
Customer Bike Therapy
Invoice Number INV-0002

Amount Due 19,100.00

Due Date 11 Jun 2015

Amount Encloded
To: L & E bicycles
985 Nichokon St Eneer the amount you are paying above

FITZROY NORTH VIC 3068

AUSTRALIA

FIGURE 10.15 (B) Sales invoice as prepared and sent to customer

Source: © Xero Limited.

Risks relating to these billing activities include failing to bill a customer for a valid sale, or billing a
customer erroneously when no goods have been shipped. To reduce these risks the organisation should
separate the billing and shipping functions and impose independent checks to ensure that goods have
been shipped prior to billing the customer. Pre-numbering shipping documents and regularly reviewing
any shipping documents not invoiced will help to detect any shipped goods that have not yet been billed,
as will regular reconciliation of sales orders to shipping documents. Alternatively, using a pre-billing
system may be appropriate.

454 PART 3 Systems in action

 Customer Invoice Report (Australian Dollar)
L & E bicycles
From 01 June 2015 to 31 July 2015

Invoice Number Reference Type To Date Due Date Expected Date Paid Date Invoice Total Paid Due Sent Status

INV-0001 INV Bike Hub 15 Jun 2015 22 Jun 2015 7,000.00 0.00 7,000.00 Sent Awaiting Payment
INV-0002 INV Bike Therapy 4 Jun 2015 11 Jun 2015 13 Jun 2015 19,100.00 19,100.00 0.00 Sent Paid
INV-0003 INV Bikes R Us 24 Jun 2015 1 Jul 2015 2,960.00 0.00 2,960.00 Sent Awaiting Payment
INV-0004 INV Bizarre Bikes 25 Jun 2015 27 Jul 2015 6,110.00 0.00 6,110.00 Unsent Awaiting Payment
Page Total 35,170.00 19,100.00 16,070.00

Report Total 35,170.00 19,100.00 16,070.00

Page 1 of 1 (4 total items) Showing 100 items per page

Export

FIGURE 10.16 Unpaid sales invoices

Source: © Xero Limited.

Paid Sent Mark as unsent ? Email Print PDF Invoice Options

To Date Due Date Invoice # Total

Bike Therapy 4 Jun 2015 11 Jun 2015 INV-0002 19,100.00
25 Leveson St
NORTH MELBOURNE VIC 3051
AUSTRALIA
Edit address

Amounts are Tax Exclusive

Item Code Description Quantity Unit Price Disc % Accont Tax Rate Amount AUD

BMX Mongoose BMX Bike 20.00 254.55 Sales GST on Income 5,090.91

Hybrid Giant B2015 Hybrid 5.00 1,427.27 Sales GST on Income 7,136.36

Road Samson Road Bike 10.00 513.64 Sales GST on Income 5,136.36
Subtotal 17,363.63

Total GST 10% 1,736.37

TOTAL 19,100.00
Less Payment 19,100.00
13 Jun 2015

AMOUNT DUE 0.00

History & Notes ?

Paid by alison parkes on 20 Jul 2015 at 17:48 p.m.

Payment received from Bike Therapy on 13 June 2015 for 19,100.00. This invoice has been fully paid.

Hide History (4 entries) Add Note

FIGURE 10.17 Paid sales order screen

Source: © Xero Limited.

CHAPTER 10 Transaction cycle — the revenue cycle 455

 When creating invoices there is a risk of error, including both over-billing and under-billing. Common
controls include using independent pricing data and/or fixed price lists and populating invoice prices
directly from those price lists. This reduces the potential for staff to deviate from corporate pricing pol-
icies, either accidentally or deliberately. In common with most risks, there are two underlying problem
areas: risks related to human error, and risks related to deliberate fraudulent activity. When creating and
assessing control plans, it is important to consider and control for both areas.
In addition to using fixed price lists, it is important to confirm customer account balances regularly.
Note, however, that this is a control for over-billing; it is not likely to detect under-billing. That is, it is
unlikely that a customer would inform you if you undercharged them; however, it is almost certain that
they would be quick to let you know if you overcharged them. An important consideration here is the
need to think about individual controls in terms of the contexts in which they operate. A control may
provide differing forms of assurance under different circumstances, and it is important to understand
exactly where and how a control plan will work.
Customer balances owing should be regularly confirmed by means of an account statement, which
is prepared and sent to customers with amounts outstanding. A customer statement is really just a
listing of all transactions recorded in the accounts receivable ledger for that customer. The transaction
types contained in a customer statement relate to invoices raised and payments received. This state-
ment is usually sent to the customer monthly, either electronically or on paper, and contains details
of the preceding month’s receipts, a list of invoices that are unpaid and their age (i.e. how long they
have been outstanding), the current balance payable and the due date for payment.
Many statements include a remittance advice for the customer to tear off, annotate and return with
their payment. This is an example of a turnaround document. Although generation of these cus-
tomer statements is almost always automated, it is important to check the statements prior to des-
patch. Statements for small amounts (usually less than $10) or statements intended for customers
who are already in a debt recovery process should not be sent. Ideally, these types of edit checks
should be automated and embedded into the statement generation program; however, if they are not,
a manual visual check is helpful.

Bill the customer — DFD

The level 1 DFD in figure 10.18 and the process map in figure 10.19 contain a lower level of detail about
the third process represented in the level 0 logical DFD in figure 10.4. This process takes place after the
goods have been despatched to the customer in the preceding process and before payment is received in
the following process.

Summary description of activities in billing

the customer
Table 10.5 summarises the activities, risks and controls involved when billing the customer, as depicted
in figures 10.18 and 10.19. Table 10.2 explains the logical data flows depicted in figures 10.18 and 10.19.
Exploring the diagram in conjunction with the material contained in the tables will assist in improving
your understanding of the process depicted.

456 PART 3 Systems in action

 1.0 2.0
Process the Pick, pack
sales order and ship goods

(25) (35)
3.1
Check sales
completion

Sales

(36)
(37)

(38)

3.2
Create invoice
(39)

(40)

Customer
Accounts
receivable

FIGURE 10.18 Revenue cycle level 1 logical diagram — process 3.0 Bill the customer

Receives sales
Customer
invoice

Updates sales Updates

Computer Creates invoice order status to accounts
‘Billed’ receivable

Goods Requests invoice

Billing officer despatched? creation

FIGURE 10.19 Revenue cycle process map — process 3.0 Bill the customer

CHAPTER 10 Transaction cycle — the revenue cycle 457

TABLE 10.5 Activities in billing the customer
Usually
Activity # Activity conducted by Activity description Typical risks encountered Common controls
3.1 Check Billing officer The billing officer Failure to bill customers Separation of billing and
sales checks that they shipping functions
completion have a matching Billing customers when no Pre-numbering shipping
shipping label for goods have been shipped documents and reviewing any
each sales order. shipping documents not
invoiced, use of a pre-billing
system (vs a post-billing system)
Reconciliation of sales order
to shipping documents
3.2 Create Billing officer An invoice is Invoice errors — Using independent
invoice created for each both over-billing and pricing data and/or fixed
valid sale. Details of under-billing price lists (see example in
the invoice are sent figure 10.20)
to the customer, Populating price data with data
and the invoice from those price lists
data is recorded Confirming customer accounts
in the customer’s regularly — note this is a control
accounts receivable for over-billing only, it will not
account. detect under-billing

Edit Item

Item Code Item Name

BMX Mongoose BMX

I track this item Inventory Asset Account

630 - Inventory

This item cant be untracked because it is associated with tracked transactions.

I purchase this item Unit Price Cost of Good Sold Account Tax Rate
216.00 310 - Cost of Goods Sold GST on Expenses

Purchases Description (for my suppliers)

Mongoose BMX Bike

I sell this item Unit Price Sales Account Tax Rate

280.00 200 - Sales GST on Income

Sales Description (for my customers)

Mongoose BMX Bike

Save Cancel

FIGURE 10.20 Internal control — setting a default sales price for an inventory item
Source: © Xero Limited.

458 PART 3 Systems in action

Receive and record payment — activities, risks
and controls
Process 4.0, receive and record payment, comprises the following activities.
Receive payment
In response to the statement, a customer usually sends payment and an accompanying remittance
advice to the organisation. A major risk here is that of late, slow or non-payment of accounts.
Prompt invoicing of customers acts to reduce this risk, as does setting suitable payment terms. The
regular and consistent follow-up of overdue accounts and the prompt removal of credit facilities
for any non-payers are also important. Ideally, a cashier would be responsible for receiving pay-
ments from customers, issuing receipts for those payments, and depositing the payments into the
company bank account. This cashier should not be assigned any other duties relating to billing or
sales activities in order to reduce the risk of fraud and error. The cashier receipts all payments and
the data is recorded as a cash receipt. These cash receipts data are often used to generate automati-
cally a bank deposit slip. Many organisations also have a mailroom where cheques are received and
recorded prior to being sent to the cashier for processing. Creating an independent record of details
of all cheques received in the mailroom is a helpful independent check of the bank deposit records,
and can help with detection of lapping and similar frauds by use of one-for-one checking against
deposit slips and cheques. The cheques and deposit slips are taken to the bank to be deposited into
the company bank account. Note that for electronic payments this step is not necessary. Accepting
and banking cash and cheque payments carries a risk of theft or misappropriation of the cash and/
or cheques. Common controls to reduce this risk include minimising the number of cash handling
points and the numbers of people handling cash. It is also important to enter cash receipts close to
when they are received; allowing undocumented cash to sit around is likely to lead to a higher level
of opportunistic theft.
Once payments have been receipted, the physical security of cash and cheques can be improved by
the use of bank lockboxes or company safes, and by banking regularly and not allowing large amounts
of cash to build up on the organisation’s premises. Cheques received should be immediately stamped or
written on (called cheque endorsement) and separated from the accompanying remittance advices. This
separation allows the cheque to be receipted and deposited by the cashier, and the payment to be allo-
cated promptly and independently by accounts receivable staff. Having two separate input points for the
cash receipts data supports later reconciliation by an independent person. In addition to these controls,
a regular bank reconciliation should be conducted by an individual who has no direct responsibility for
any other revenue or expenditure activities.
Record payment
If a payment is made electronically, the cashier will need to download and reconcile the online
banking transactions and use this data to populate the cash receipts records. If online banking is
used, it is important to limit access to the online bank accounts and to prepare regular customer
receipts and statements. Once a payment has been receipted, it can be recorded against the ­customer’s
accounts receivable account. The accounts receivable officer must examine details of all unpaid
invoices and the customer-completed remittance advice in order to determine how to allocate the pay-
ment received.
Receipt allocation is the process of allocating the total payment received against one or more of the
unpaid invoices in the customer’s accounts receivable account. Those invoices that have a payment
allocated against them need to be updated with a status of ‘paid’ (this is also known as an invoice
being ‘closed’). There is a risk that payments received will be incorrectly recorded against the cus-
tomer accounts. To control this potential problem it is important to create batch totals or hash totals
of cash receipts and reconcile all inputs to accounts receivable. The use of regular customer state-
ments is also important; however, these will only detect any amounts under-receipted — any amounts

CHAPTER 10 Transaction cycle — the revenue cycle 459

over-receipted may not be detected using this control as discussed earlier in relation to under- and
over-billing. Data generated by billing and accounts receivable activities is transferred through to the
financial cycle, where it is used to update general ledger accounts and create reports as described in
chapter 13.

Receive and record payment — DFD

The level 1 DFD in figure 10.21 and the process map in figure 10.22 contain a lower level of detail about
the final process represented in the level 0 logical DFD in figure 10.4. This process takes place after the
customer has been billed in the preceding process.

Customer

Cash receipts

(42)
Customer (43)
(45)

4.1 (41)
(44) Receive
payment

Accounts
receivable
(46)
(47)
(48)

Bank (49)

4.2
Record
payment

(50)

Financial
cycle

FIGURE 10.21 Revenue cycle level 1 logical diagram — process 4.0 Receive and record payment

460 PART 3 Systems in action

 Receives
Customer monthly Sends payment
statement

Prepares
Updates invoice
Computer monthly Records receipt
status to ‘Paid’
statements

Requests
Accounts Receipt Records receipt
monthly
receivable allocation? allocation
statements
officer

Receipts and
Cashier deposits
payment

Bank Receives deposit

FIGURE 10.22 Revenue cycle process map — process 4.0 Receive and record payment

Summary description of activities in receiving and

recording payment
Table 10.6 summarises the activities, risks and controls when receiving and recording payment, as
depicted in figures 10.21 and 10.22. Table 10.2 explains the logical data flows depicted in figures 10.21
and 10.22. Exploring the diagram in conjunction with the material contained in the tables will assist in
improving your understanding of the process depicted.

CHAPTER 10 Transaction cycle — the revenue cycle 461

TABLE 10.6 Activities in receiving and recording payment
Usually Activity Typical risks
Activity # Activity conducted by description encountered Common controls
4.1 Receive Accounts The accounts Late/slow/ Prompt invoicing, and setting suitable
payment receivable receivable officer non-payment of payment terms
officer/ prepares a customer accounts Regularly and consistently following up overdue
cashier account statement accounts (see example in figure 10.23)
which is sent to the
Removing credit facilities for any non-payers
customer.
The cashier
receives payments Theft of cash and/ Minimising the cash-handling points and the
from customers, or cheques numbers of people handling cash
issues receipts,
and deposits the Entering cash receipts close to when
payment into the payments received
company bank Using lockboxes or safes and banking regularly
account. Immediate/prompt cheque endorsement and
If a payment is immediate separation of remittance advice
made electronically, and cheques
the cashier will One-for-one checking of deposit slips and
download and cheques
reconcile the online
Regular bank reconciliations by an
amounts.
independent person
Limiting access to online banking
Preparing regular customer statements
4.2 Record Accounts The accounts Incorrect recording Creating batch or hash totals of cash receipts
payment receivable receivable officer of customer and reconciling inputs to accounts receivable
officer enters the details of accounts Issuing regular customer statements,
cash received into the incorporating turnaround documents
customer’s accounts
receivable account

Aged Receivables Detail

L & E bicycles
As at 20 July 2015

Invoice Date Due Date Invoice Number Invoice Reference Current < 1 Month 1 Month 2 Months 3 Months Older

Bikes Hub
15 Jun 2015 22 Jun 2015 INV-0001 - 7,000.00 - - - -

Total Bike Hub 0.00 7,000.00 0.00 0.00 0.00 0.00

Bikes R Us
24 Jun 2015 1 Jul 2015 INV-0003 - 2,960.00 - - - -

Total Bike R Us 0.00 2,960.00 0.00 0.00 0.00 0.00

Bizarre Bikes
25 Jun 2015 27 Jul 2015 INV-0004 6,110.00 - - - - -

Total Bizarre Bikes 6,110.00 0.00 0.00 0.00 0.00 0.00

Total 6,110.00 9,960.00 - - - -

FIGURE 10.23 Internal control — report of Accounts Receivable aged outstandings

Source: © Xero Limited.

462 PART 3 Systems in action

Physical DFD — process the sales order
The physical DFD depicted in figure 10.24 shows an example of how a sales order may be processed.
The physical diagram draws the process from a different perspective to the logical DFD of this process
contained in figure 10.9, as it shows who is involved in the activities of the process, rather than when
those activities occur. This processing of a sales order involves the sales officer and the sales manager,
who both interact with a central computer. The sales officer also interacts with the customer during this
process. Outputs from this process are sent through to the production and HR cycles, and also to the
picking officer and billing officer for use in subsequent parts of the revenue cycle.
Details of the physical data flows in figure 10.24 are contained in table 10.7. As this diagram is drawn
from a different perspective to the logical DFD, it contains far more detail about the interactions between
each of the entities involved in processing the sales order.

Production
cycle

Customer (1) (5)

(17) 1.0
Sales officer (2) Inventory
(4)
(7)
(16)
(11)
(13) (3) Customers
(15)

2.0 (8)
Computer (9)
(18)
(20)
Accounts
(10)
(21) receivable
(23) (14)
3.0 (19)
Sales manager (22)

HR cycle
(24) (25) Sales

Picking officer Billing officer

FIGURE 10.24 Physical DFD — process 1 Process the sales order

CHAPTER 10 Transaction cycle — the revenue cycle 463

TABLE 10.7 Description of data flows in physical DFD and flowchart in processing the sales order

Data
Flow # Data source destination Explanation of the physical data flows

1 Customer Sales officer The customer posts a paper purchase order to the sales officer containing
details of the goods the customer wants to purchase.

2 Sales officer Computer The sales officer inputs a request for stock levels of requested products
into the computer.

3 Inventory data store Computer The required stock levels are extracted from the inventory data store.

4 Computer Sales officer The requested stock levels are displayed to the sales officer.

5 Sales officer Production The sales officer sends details of goods required to be produced to the
cycle production cycle.

6 Sales officer Sales officer When the inventory check is complete the credit check can commence (not
depicted in a physical DFD).

7 Inventory check Computer The sales officer inputs a request for a credit check on the customer into
the computer.

8 Customer data store Computer The computer extracts the customer’s credit limit from the customer data
store.

9 Accounts receivable Computer The computer extracts the current accounts receivable balance for the
data store customer from the customer data store.

10 Sales data store Computer The computer extracts details of any recent sales that have not yet been
posted to accounts receivable for the customer from the sales data store.

11 Computer Sales officer The computer displays the result of the credit check for the customer to
the sales officer.

12 Sales officer Sales officer Once the credit check is complete, the sales order can be created (not
depicted in a physical DFD).

13 Sales officer Computer The sales officer inputs a request to create the sales invoice into the
computer.

14 Computer Sales data store The computer stores details of the sales order in the sales data store.

15 Computer Sales officer The computer displays the completed sales order to the sales officer.

16 Computer Inventory data The computer marks the relevant inventory item status as ‘promised’ in the
store inventory data store.

17 Sales officer Customer The sales officer advises the customer whether the sale will proceed.

18 Sales manager Computer The sales manager requests the computer to create a report of sales
commission payable.

19 Computer Sales data store The computer extracts details of sales on which commission is payable
from the sales data store.

20 Computer Sales manager The computer displays sales commission payable to the sales manager.

21 Sales manager Computer The sales manager inputs an authorisation to pay the sales commissions.

22 Computer Sales data store The status of the relevant sales is updated to ‘commission approved’.

23 Computer HR cycle The computer transfers details of commissions payable to the HR cycle.

24 Computer Picking officer The computer sends details of the sales order to the picking officer.

25 Computer Billing officer The computer sends details of the sales order to the billing officer.

464 PART 3 Systems in action

Systems flowchart — process the sales order
The DFD in figure 10.24 shows an example of how a sales order may be physically processed. The
logical DFD in figure 10.9 shows that same process from a logical perspective, while the process map
in figure 10.10 shows a high-level depiction of the process. The flowchart contained in figure 10.25
shows that same process from yet another perspective. The systems flowchart in figure 10.25 is the most
detailed picture of the process, and includes both logical and physical perspectives. The detail contained
in the systems flowchart is useful when considering process redesign, and when analysing the control
environment of the process depicted. Details of the flows shown in the flowchart are documented in
table 10.7.

Sales clerk Computer Sales manager

Customer

Process inventory
(3)
level request Inventory
Sales request
(2)
(1)

Request inventory (4) (8)

Customer
levels

Inventory Process credit

check (9)
levels Accounts
(5) receivable
Production (6) (7)
cycle (10)
Request credit (11)
check

Credit check Sales

(19)
result Create sales
commissions (18) Request sales
(12) (14) report commissions report

Request create (13) Create sales

sales order order (22) Display sales
(20)
commissions
(16)
Completed (15)
sales order (24)
Inventory
(17) (25) Process approved
(21) Approve sales
Picking officer commissions commissions
Customer
(23)
Billing officer
HR cycle

FIGURE 10.25 Systems flowchart — process the sales order

CHAPTER 10 Transaction cycle — the revenue cycle 465

10.6 Measuring revenue cycle performance
LEARNING OBJECTIVE 10.6 Justify metrics to monitor revenue cycle performance.
Cycle performance should be measured relative to how well the process outcomes achieve the overall objec-
tives of that cycle. At the start of this chapter the objectives of the revenue cycle were described as being to
effectively conduct, record and monitor sales of goods and services; to arrange the prompt supply of goods
and services; and to ensure payments for goods and services are correctly received, recorded and banked.
To monitor performance against these objectives a range of metrics needs to be employed, along with
some realistic targets. Figure 10.26 shows an example of the analytical data available for performance
evaluation of the supply of goods and services to customers.

L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Sales

+ New Send Statements Import Search

Invoices Paid Repeating See all

Draft Awaiting Approval Awaiting Payment (3) Overdue (2)

None None 16,070.00 9,960.00

Money coming in Customers owing the most List Pie

8,000
Bike Hub 7,000.00 7,000.00

Bizarre Bikes 6,110.00

4,000
Bikes R Us 2,960.00 2,960.00

Older Apr May Jun Jul Future

FIGURE 10.26 Customer invoice analytics

Source: © Xero Limited.

Examples of suitable metrics or key performance indicators (KPIs) for the revenue cycle objectives
are shown in table 10.8

TABLE 10.8 Example KPIs mapped to cycle objectives

Objective Example KPI
To effectively conduct, record and monitor sales of • Number of data entry errors detected
goods and services • Customer complaints/satisfaction
• Credit requests
• Number of credit memos raised due to billing errors
• % sales invoiced on day of shipping
To arrange the prompt supply of goods and services • Cycle time to fill and deliver orders
• % of sales on back order
• Sales returns
To ensure payments for goods and services are • Aged accounts receivable reporting
correctly received, recorded and banked • Number of bad debts written off
• Average payment times

466 PART 3 Systems in action

SUMMARY
10.1 Reflect on the key objectives and strategic implications of the revenue cycle.
The revenue cycle is divided into two major processes: sales and accounts receivable. The sales process
is client facing as it is where the sales transaction takes place. The objective of the sales process is to
effectively conduct, record and monitor sales of goods and services, and arrange the prompt supply of
goods and services. Following directly on from sales is the accounts receivable process, where the objec-
tive is to ensure payments for goods and services are correctly received, recorded and banked.
The revenue cycle is strategically important as the level of sales activity is a primary driver for the
organisation. To survive long term an organisation must not only remain profitable (i.e. revenues must
exceed expenses), it also must be able to achieve positive cash flows. A sound, well-controlled revenue
cycle can provide a competitive advantage by delivering superior customer service levels, which in turn
can translate to opportunities to sustain higher product price levels. An alternative form of competitive
advantage afforded by a revenue cycle that is efficient and effective is the potential to control costs. This
translates into an opportunity to price goods and services at a level that potentially undercuts the prices
of less efficient competitors, and to increase market share. It is important to align the objectives of the
revenue cycle with the organisation strategy that overarches all the businesses within the organisation.
10.2 Evaluate common technologies underpinning the revenue cycle.
Activities within the revenue cycle benefit from underpinning technologies that improve the ability to cap-
ture and analyse revenue data and manage cash and cash flows. Enterprise resource planning (ERP) systems
assist with enabling and integrating activities across the enterprise, and technologies to support efficient data
exchange such as EDI and XML help provide efficient exchanges of revenue data. Management of outgoing
inventory forms a significant component of the revenue cycle; the conduct of inventory-related activities can
be improved by the use of barcode scanners and readers, whereas scanning incoming documents will support
faster transaction processing. A revenue data warehouse will support data mining to improve understanding
of markets and product performance. The opportunity to improve understanding of individual customers
is afforded by customer relationship management (CRM) systems, which present a customer-centric view
of process activities and outcomes. Online payment and banking facilities provide a cost-effective way for
organisations to receive and monitor payments. Use of these facilities cuts costs and reduces error rates.
10.3 Recognise revenue cycle data and key revenue business decisions.
The revenue cycle uses or produces data including customer, inventory, accounts receivable and sales
data. Process business decisions are made at both strategic and operational levels. Strategy-level decisions
include the creation of policies such as price setting, sales return and warranty policies, provision of cus-
tomer credit facilities, and cash collection policies and procedures. Typical operational decisions include
responding to customer inquiries such as a request to purchase goods or to return goods for credit or a
request to extend credit to a particular customer, calculation of inventory availability, selecting a goods
delivery method and determining the correct cash receipt allocations for a customer payment.

10.4 Summarise and prepare documentation synthesising the primary activities in the
revenue cycle and the data produced by these activities.
Contextually, the revenue cycle involves direct interaction with entities outside the organisation such as
customers, couriers and banks. Within the organisation, the revenue cycle interacts with the production,
HR management and payroll, and general ledger and financial cycles. Primary activities in the revenue
cycle include processing the sales order, despatching goods to the customer, billing the customer and
receiving and recording payments.
A range of data types are accessed by activities within the revenue cycle including customer data,
inventory data, accounts receivable data, cash receipts data, sales data and accounts receivable adjust-
ments data. Revenue data is used to support decision making related to the revenue cycle, and for evalu-
ating process performance and reporting financial results for the organisation.

CHAPTER 10 Transaction cycle — the revenue cycle 467

10.5 Assess risks and compose control plans pertinent to the primary activities in the
revenue cycle.
Activities within the revenue cycle create exposure to a range of known risks. Risks related to customer
accounts include failing to bill customers, or not billing customers correctly, data entry errors, late/slow/
non-payment of customer accounts, slow processing of sales orders, raising inappropriate credit memos,
and bad or doubtful debt recording errors.
Risks related to the inventory management aspect of the revenue cycle activities include making
errors when picking and packing goods for despatch, theft of inventory, incorrectly recording goods
movements, despatching incorrect goods to customers, and slow shipment of goods.
To reduce risk exposure, the control environment must include controls that minimise human error,
as well as prevent fraudulent behaviour. Controls need to be created over both manual and automated
activities, and some degree of control redundancy should be embedded in the control environment.
Important controls in the revenue cycle include performing credit checks, maintaining perpetual inven-
tory records, appropriate segregation of duties, exception reporting, regular monitoring of customer out-
standings, regularly issuing statements to customers and performing regular bank reconciliations.
10.6 Justify metrics to monitor revenue cycle performance.
Cycle performance should be measured relative to the desired outcomes of the process. To monitor cycle
performance a wide range of metrics needs to be employed, along with some realistic targets. Examples
of suitable performance metrics for a revenue cycle include numbers of data entry errors, customer satis-
faction levels, cycle times at both process and activity levels, volume of back orders and sales returns,
accounts receivable ageing, number of bad debts written off and average payment times achieved.

KEY TERMS
Back order An order used where a customer has asked to purchase goods which the organisation
does not currently have available. A back order records the customer request for the goods, with the
intention of supplying the goods at a later date once they become available.
Batch process A type of transaction processing where transactions are saved up until there are a
number ready to be processed (a batch), then processed together. Batch processing is typically used
to improve controls over data entry and provide efficiency gains. Batch processing is most useful
where timeliness is not an issue as there is always some delay in processing transaction batches.
Batch total A total that is added to a batch of documents and is used to make sure that all documents
in the batch have been correctly processed. A batch total is usually a summation of data items with
some meaning (e.g. a total of the individual invoice amounts for a batch of invoices). See also hash
total.
Cheque endorsement Stamping or writing on a cheque to stop the cheque being diverted to a
different bank account than that intended. An endorsement often is written as, for example, ‘Not
Negotiable — pay only to Smith & Co’.
Customer relationship management (CRM) Software designed with the specific purpose of viewing
the organisation’s data from a customer-centric perspective that monitors and helps the management
of customer interactions with the organisation. Examples include Siebel and SAP.
Electronic data interchange (EDI) A bespoke link that enables exchange of data between two
separate computer systems. Used when transaction flow and volume is large and transaction syntax
is predictable.
Enterprise resource planning (ERP) system An integrated suite of software that records and
manages many different types of business transactions within a single integrated database. Examples
include SAP and Oracle.
Exception report A report type that is designed specifically to identify exceptions for particular
transactions. An example is a report identifying any sales orders which have been shipped but not
billed, or a report identifying all customers who have overdue accounts receivable accounts.

468 PART 3 Systems in action

eXtensible Markup Language (XML) A hypertext language which is used to add syntax to strings
of data by embedding semantic tags. Useful for transaction processing where the data syntax is
predictable and well defined.
Hash total A total that is similar to a batch total but the number that is added has no meaning by itself
(e.g. a hash total of customer numbers). See also batch total.
Metric A specific measure used for a particular purpose. An example of a metric is the number of bad
debts the organisation has, which could be used to monitor accounts receivable or sales performance.
Post-billing system A billing system where the customer is billed for the goods after the goods are
despatched.
Pre-billing system A billing system where the customer is billed for the goods before they are
despatched. Payment should also be received before goods are despatched. Very common in online
sales environments.
Reconciliation An activity where two different sets of data that purport to represent one transaction or
set of events are compared to see if they agree. A common example is a bank reconciliation, which
reconciles the organisation’s accounting records of cash inflows and outflows with the bank’s record
(i.e. a bank statement).
Status code A code on transactions that are moving through an iteration of a process indicating which
stage of the process the transaction is at. As an example, a sales transaction may be first ‘created’,
then ‘picked’, then ‘packed’ then ‘shipped’ then ‘paid’. When each of these activities has been
completed the status of the transaction is changed to reflect the new status.
Turnaround document A document that is printed with a separate section designed to be detached,
completed and returned to the issuing organisation. Examples include a tear-off section on a delivery
docket which is signed and returned to a courier.

DISCUSSION QUESTIONS
10.1 Berwick Ltd has always had a strategy of cost leadership; that is, selling high volumes of
low-cost products at a competitive price. During a recent sales slump, Berwick Ltd saw its sales
revenues drop dramatically and has decided to move strategically to a product differentiation
strategy; that is, to sell lower volumes of high-quality products at a premium price.
(a) What are the implications of this strategy change for the revenue cycle? (LO1)
(b) What changes would you expect to see in the revenue cycle? (LO4)
(c) What are the implications of this strategy change in terms of the usefulness of
historical sales data for decision making? (LO3)
10.2 Mascolo Ltd has decided to introduce PayPal to allow their customers to pay for goods
they have bought online.
(a) What controls would you expect to see introduced to ensure the safety of Mascolo’s
customer data? (LO5)
(b) Which activities in the receive and record payment process will be affected? (LO2, LO4)
(c) What changes would you expect to see in these activities? (LO4)
(d) What metrics could you use to measure the success of this initiative post
implementation? (LO6)
10.3 Stannus Ltd has just realised that it has a problem with sales data as its sales order system
records sales to customers that subsequently fail a credit check.
(a) What decisions made during the revenue cycle would be affected by this data
problem?  (LO3, LO4)
(b) How would those decisions be affected? How would this data problem affect
the performance of the revenue cycle? (LO3, LO4, LO6)
(c) How would this data problem affect other processes at Stannus Ltd? (LO1, LO3, LO4, LO6)

CHAPTER 10 Transaction cycle — the revenue cycle 469

10.4 Prior Ltd has a reconciliation problem. The amount of cash receipted and banked by the
cashier does not seem to agree with the amount allocated against open invoices in the accounts
receivable customer records. Prior Ltd seems to have good controls — it separates the receipting
and recording of cash, and it regularly conducts a reconciliation.
(a) Which internal controls might be missing? (LO5)
(b) What documentation would you examine in order to investigate this problem? (LO4)
10.5 Dowling Ltd has a new Sales Manager who is keen to improve process efficiency. She has
reviewed the process documentation for the sales cycle and has asked you to remove the credit
check as it is slowing down the sales process and she is concerned Dowling Ltd is losing sales as
a result.
(a) Should you agree to remove the credit check? Why or why not? (LO1, LO3, LO5)
(b) If you do not agree with removing the credit check, how would you explain this decision to
the CEO? (LO1, LO5)
(c) If you do agree with removing the credit check, how would you justify this change to the
Accounts Receivable Manager? (LO1, LO5)
(d) If you remove the credit check, will you need to measure the process performance
differently? (LO1, LO6)

SELF-TEST ACTIVITIES
10.1 Which of the following drives the activity levels of a business? (LO1)
(a) The business strategy.
(b) The number of customers.
(c) The number of different products sold.
(d) The level of sales.
10.2 A well-aligned revenue cycle is congruent with the: (LO1)
(a) organisational goals.
(b) organisational strategy.
(c) organisational culture.
(d) all of the above.
10.3 Use of barcode scanning technology could not help to: (LO2)
(a) improve customer payment times.
(b) improve data timeliness.
(c) reduce data errors.
(d) speed up data collection.
10.4 Correctly calculating the amount of inventory on hand does not require knowledge of: (LO3)
(a) stock on hand.
(b) stock on order.
(c) supplier lead times.
(d) stock shipped to customers.
10.5 The revenue cycle interacts internally with: (LO4)
(a) the production cycle.
(b) the HR management and payroll cycle.
(c) the financial cycle.
(d) all of the above.
10.6 Primary risks of the revenue cycle include: (LO5)
(a) customers not paying for goods.
(b) slow dispatch of goods.
(c) theft of inventory.
(d) all of the above.

470 PART 3 Systems in action

 10.7 A credit check should be performed:(LO5)
(a) for new customers.
(b) for new products.
(c) for all sales.
(d) for slow-paying customers.
10.8 It is not necessary to check shipping label details when: (LO3)
(a) the customer buys products frequently from you.
(b) the same person who picks the goods also packs and labels them.
(c) the delivery driver is going to check this anyway.
(d) none of the above — you should always check the label.
10.9 Not reconciling invoices raised by the billing system with shipping documents increases
the risk of: (LO5)
(a) not billing the customer.
(b) shipping the wrong goods to customers.
(c) not shipping goods to customers.
(d) picking the wrong goods.
10.10 Sending customers a regular statement of account helps to detect: (LO5)
(a) under-billing only.
(b) over-billing only.
(c) neither (a) nor (b).
(d) both (a) and (b).
10.11 Monitoring the number of bad debts written off is useful to determine: (LO5)
(a) how accurately sales of goods and services are recorded.
(b) how promptly goods and services are delivered.
(c) how well the credit check control is working.
(d) how well payments are recorded.

PROBLEMS
The case narrative below (AB Hi-Fi) will be used to complete problems 10.1–10.14. Make sure you read
and understand the activities and the case thoroughly before you commence work on the problems.

AB Hi-Fi revenue cycle

AB Hi-Fi is a multi-store retail business that sells products such as DVDs, CDs, mp3 players, game
consoles and TVs. In addition to these retail sales, AB Hi-Fi also sells music, games and DVDs via its
website. The narrative of the revenue cycle relating to online sales at AB Hi-Fi follows.
Process 1.0 Process the sales order
Customers browse the AB Hi-Fi online store looking for products to purchase from the product cata-
logue. When they have located an item they wish to purchase, they click on a ‘buy this item’ link located
underneath the item required. The computer displays a screen showing the product ID number and asks
the customer to enter the quantity of the item required. The customer keys in the quantity required. The
computer then displays a screen asking the customer if they want to continue shopping. Once the cus-
tomer indicates that they do not want to continue shopping, the computer calculates and displays an
order confirmation screen containing the product ID number, product price, quantity and total cost per
item for each different item ordered, the shipping amount (AB has a standard shipping rate within Australia
of $10 per delivery), and a total for all items and shipping costs. The screen asks the customer to input
their credit card and delivery details to complete the order. The customer inputs the delivery details (name
and address) and credit card details (card number and expiry date) to the order confirmation screen.

(continued)

CHAPTER 10 Transaction cycle — the revenue cycle 471

(continued)

The computer assigns the next sales order number to the transaction, then displays a screen for the
customer, which provides the sales order number and confirms that the order has been completed. The
computer records the sales order details in the sales event data store. At 11 pm every evening the com-
puter extracts details of the day’s sales and updates the inventory levels. The computer prints a picking
ticket (barcoded sales order number, items and quantities) on the warehouse printer and produces an
electronic credit card check file listing all the credit card details (customer name, credit card number
and expiry date) from the previous day’s sales.
Process 2.0 Pick, pack and ship the goods
At 8 am every morning, the warehouse officer collects the picking tickets from the warehouse printer and
picks the required goods from the shelf. If any of the goods are not available, the warehouse officer puts
back any goods they have already picked for the order and places the picking ticket in a folder on their desk
labelled ‘awaiting goods’. If all the goods are available, the warehouse officer takes the goods and the picking
ticket to the shipping department. The shipping officer scans the sales order number from the picking ticket,
and the computer displays the order on the screen. The shipping officer manually checks each item picked
against the original sales order and the picking ticket. The shipping officer also checks the name on the sales
order against the names highlighted on the credit card status report. If the name on the order matches a name
on the credit card status report, the goods and the picking ticket are sent back to the warehouse with a note
attached indicating they cannot be shipped due to non-payment. Once they are satisfied that the credit card
payment is not invalid, and that the correct items are being shipped, the shipping officer checks a box on the
sales order to indicate that shipping is complete. The computer updates the sales order and inventory data.
The computer also prints a delivery slip for the order on a printer in the shipping department. The shipping
officer attaches the delivery slip to the goods and places them on the loading dock. Every day at 3 pm, a car-
rier picks up the goods from the loading dock and delivers them to the customers.
Process 3.0 Bill the customer
The computer sends the electronic credit card check file that was produced at 11 pm to the bank’s computer
for verification. At 1 pm every day, the bank sends an electronic report via email to the accounts receiv-
able officer indicating the status of each of the credit card orders (valid/invalid). The accounts receivable
officer prints out two copies of the credit card status report. The accounts receivable officer files one copy
of the credit card status report and uses a highlighter pen to mark out on the second copy the name of any
customers whose credit card was reported as invalid. The accounts receivable officer takes the highlighted
report to the shipping officer who is responsible for checking that these customers do not receive any goods.
Process 4.0 Receive and record payment
Immediately after the bank sends the electronic status report, the funds for all valid credit card orders
are transferred into the company’s bank account. The accounts receivable officer receives an email from
the bank advising them of the total amount of the funds transferred. The accounts receivable officer
compares the total in the email to the total in the credit card status report. If these totals agree, the
amount is input into the computer and the cash receipt data store is updated. If the totals do not match,
the problem is referred to the accounts receivable manager for resolution.

10.1 Prepare a context diagram for the revenue cycle at AB Hi-Fi. (LO4)
10.2 Prepare a level 0 logical DFD for the revenue cycle at AB Hi-Fi. (LO4)
10.3 Prepare a process map for: (LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
10.4 Prepare a level 1 logical DFD for: (LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.

472 PART 3 Systems in action

 10.5 Prepare a physical DFD for: (LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
10.6 Prepare a systems flowchart for: (LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
10.7 Table 10.3 identifies 11 risks typically encountered when processing a sales order. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the sales process at AB Hi-Fi.
(b) Determine how many of the common controls described in table 10.3 are present in the
sales process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
sales process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the sales
process at AB Hi-Fi in order to reduce the level of risk.
10.8 Table 10.4 identifies eight risks typically encountered when despatching a sales order. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the goods despatch process at AB Hi-Fi.
(b) Determine how many of the common controls described in table 10.4 are present in the
goods despatch process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
goods despatch process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the goods
despatch process at AB Hi-Fi in order to reduce the level of risk.
10.9 Table 10.5 identifies three risks typically encountered when billing a sale. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the billing process at AB Hi-Fi.
(b) Determine how many of the common controls described in table 10.5 are present in the
billing process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
billing process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the billing
process at AB Hi-Fi in order to reduce the level of risk.
10.10 Table 10.6 identifies three risks typically encountered when receiving and recording
payments. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the receiving payments process at
AB Hi-Fi.
(b) Determine how many of the common controls described in table 10.6 are present in the
receiving payments process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
receiving payments process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the receiving
payments process at AB Hi-Fi in order to reduce the level of risk.
10.11 AB Hi-Fi has adopted a cost leadership strategy. Its overall plan is to undercut competitors on
pricing and so gain market share.

CHAPTER 10 Transaction cycle — the revenue cycle 473

 (a) How well does its current revenue cycle align with this business strategy?
(b) Are there any opportunities to improve the degree of alignment between the revenue cycle
and the business strategy? Explain what you would change and how this would improve the
strategic alignment. (LO1)
10.12 (a) Identify and describe the technologies that AB Hi-Fi uses in its revenue cycle activities.
(b) For each of those technologies you identified in part (a), how well does AB Hi-Fi use the
technology? Could you suggest a way to improve the business benefit obtained by use of
any of these existing technologies?
(c) Are there other suitable technologies available that AB Hi-Fi could be using for the revenue
cycle activities? What additional technologies could AB Hi-Fi implement? What business
benefit would these additional technologies provide? (LO2)
10.13 During process 2.0 Pick, pack and ship the goods at AB Hi-Fi, a shipping officer has to decide
whether to complete the shipment of goods to a customer. Take a moment to review this section
of the narrative before you complete the following questions. (LO3)
Required
(a)
What data does the shipping officer draw on when making the decision?
(b)
Where do the data you identified in part (a) come from?
(c)
Are these data reliable, that is, is there any possibility that there could be errors in the data?
(d)
Are these data sufficient to make the decision, or can you identify additional data that the
officer should consider when making the decision?
(e) What would be the consequences of an incorrect decision?
10.14 Explain how you would measure performance of the revenue cycle at AB Hi-Fi, specifically: (LO6)
(a) What metrics would you use to measure performance?
(b) For each metric, explain where you would obtain the data required for that metric.
(c) For each metric, explain why it is a good metric to help measure how well the revenue
cycle is meeting its objectives.

The case narrative below (AB Hi-Fi) will be used to complete problems 10.15–10.22. Make sure you read
and understand the activities and the case thoroughly before you commence work on the problems.

AB Hi-Fi record payments process

AB Hi-Fi is a multistore retail business that sells products such as DVDs, CDs, mp3 players, game
consoles and TVs. In addition to these retail sales, AB Hi-Fi also sells music, games and DVDs via its
website. The narrative of the recording payments process for AB Hi-Fi follows.
In addition to prepaid online sales and retail cash sales, AB Hi-Fi offers a credit facility to selected larger
customers. These customers receive invoices when they purchase goods and are sent a statement at the
end of each month. Payments made by these customers are received by the cashier. Every morning the
accounts receivable officer receives a report of customer receipts from the cashier. The customer receipts
report contains the customer number and name, the amount received from each customer and the total
of the customer receipts. The accounts receivable officer logs on to the computer and opens a new cash
receipts batch. The accounts receivable officer enters the first customer number from the customer receipts
report. The computer displays details of the open (unpaid) invoices for that customer. The accounts receiv-
able officer selects the invoices that have been paid by clicking on a check box. The computer calculates a
total for the customer based on the invoices checked. Once the accounts receivable officer has checked that
they have selected the correct invoices and that the customer total matches the total received by the cashier
from that customer, they authorise the receipt allocation. The computer records the cash receipt total and
changes the status of the selected invoices from ‘open’ to ‘closed’ (paid). The accounts receivable officer
does this for every customer receipt on the report. Once all the customer receipts have been entered, the
accounts receivable officer updates the computer to record the cash receipts batch as complete. The com-
puter automatically prints out a report that contains details of the cash receipts batch. The accounts receiv-
able officer attaches the cash receipts batch report to the customer receipts report and files them away.

474 PART 3 Systems in action

10.15 Prepare a context diagram for the recording payments process at AB Hi-Fi. (LO4)
10.16 Prepare a process map for the recording payments process at AB Hi-Fi. (LO4)
10.17 Prepare a level 0 logical DFD for the recording payments process at AB Hi-Fi. (LO4)
10.18 Prepare a physical DFD for the recording payments process at AB Hi-Fi. (LO4)
10.19 Prepare a systems flowchart for the recording payments process at AB Hi-Fi. (LO4)
10.20 Table 10.5 identifies three risks typically encountered when receiving and processing a
payment. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the record payments process
at AB Hi-Fi.
(b) Determine how many of the common controls described in table 10.5 are present in the
recording payments process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
recording payments process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the recording
payments process at AB Hi-Fi in order to reduce the level of risk.
10.21 During the recording payments process at AB Hi-Fi the accounts receivable officer has to
decide which open invoices to allocate the cash receipts amount against. Take a moment to
review this section of the narrative before you complete the following questions. (LO3)
Required
(a)
What data does the accounts receivable officer draw on when making the decision?
(b)
Where does the data you identified in part (a) come from?
(c)
Are these data reliable, that is, is there any possibility that there could be errors in the data?
(d)
Are these data sufficient to make the decision, or can you identify additional data that the
officer should consider when making the decision?
(e) What would be the consequences of an incorrect decision?
10.22 Consider how you would measure performance of the recording payments process at AB Hi-Fi,
specifically: (LO6)
(a) What metrics would you use to measure performance?
(b) For each metric, explain where you would obtain the data required.
(c) For each metric, explain why it is a good metric to help measure how well the revenue
cycle is meeting its objectives.
The case narratives below for Yayy Online will be used to complete problems 10.23–10.37. Make sure you
read and understand the activities and the case thoroughly before you commence work on the problems.
Yayy is a specialised online store that sells only one product each day. In addition to selling only one
product each day, Yayy offers the product of the day for sale until their stock runs out, or until the end
of the day, whichever comes first. Typical Yayy products are inexpensive (generally between $15 and
$50), and are mostly technology-related gadgets.

Yayy Online — processing a sales order

At midnight every day, the product-of-the-day web page is released and the product is then available for
sale. Customers browse the website and, if they wish to purchase the product for the day, select a ‘sell it
to me’ button. Once this button is clicked, a login screen is presented. Existing customers will key in their
username and login; new customers are routed to a registration screen to input their name and address
details and create a login. Most customers are new to Yayy. After the customer has successfully logged on,
they type in the number of products they want to purchase and select their preferred payment option. Once
the number of products required has been input and saved, the total cost of the order is calculated and dis-
played. Yayy charges a flat rate for shipping within Australia, which is added on to the price of the product/s.
Yayy offers payment via credit card or PayPal; most customers choose to pay via credit card. After the cus-
tomer keys in their payment details the data are sent to the bank (or PayPal) for verification.

CHAPTER 10 Transaction cycle — the revenue cycle 475

10.23 Prepare a context diagram for processing a sales order at Yayy Online. (LO4)
10.24 Prepare a process map for processing a sales order at Yayy Online. (LO4)
10.25 Prepare a level 0 logical DFD for processing a sales order at Yayy Online. (LO4)
10.26 Prepare a physical DFD for processing a sales order at Yayy Online. (LO4)
10.27 Prepare a systems flowchart for processing a sales order at Yayy Online. (LO4)

Yayy Online — picking, packing and shipping goods

At 7 am every day, the computer automatically extracts details of the name and shipping address of
each person who purchased goods on the previous day. The computer prints out a delivery label for
each customer, and calculates and prints out the total number of orders to be packed on the warehouse
printer. Yayy goods are delivered in padded post bags which are prepurchased in bulk through Australia
Post and include prepaid delivery. The warehouse officer picks up the delivery labels and order report
from the printer at 9 am daily and then collects sufficient prepaid postage bags from the mailroom
officer to pack the day’s orders.
After the warehouse officer has collected the post bags and the labels, they package the goods for
delivery. Each delivery label contains the customer name and address, and a number in the bottom
right-hand corner which indicates how many of the product are included in each order; most orders are
for one or two items. The warehouse officer packs the individual items into the prepaid bags, then seals
the bag and attaches the delivery label to the front of the prepaid bag. If there are not enough products
to fill all orders, the warehouse officer notifies the supplier via phone and requests more of the product
be despatched to cover the shortfall. If there are any products left over, the warehouse officer notifies
the sales manager verbally of the number of products left. Any leftover products are locked in a secure
cabinet located in the packing room. Once the packing has been completed, the delivery officer calls
Australia Post and asks them to come and collect the goods. The delivery officer leaves the packed
goods on the delivery dock for the Australia Post courier to collect.

10.28 Prepare a context diagram for picking, packing and shipping the goods at Yayy Online. (LO4)
10.29 Prepare a process map for picking, packing and shipping the goods at Yayy Online. (LO4)
10.30 Prepare a level 0 logical DFD for picking, packing and shipping the goods at Yayy Online.(LO4)
10.31 Prepare a physical DFD for picking, packing and shipping the goods at Yayy Online. (LO4)
10.32 Prepare a systems flowchart for picking, packing and shipping the goods at Yayy Online. (LO4)

Yayy Online — receiving and recording a payment

When the ‘pay via credit card’ option is selected, the website presents a screen which allows the
customer to check that their shipping and billing addresses are correct. If the address is incorrect,
the customer clicks on the ‘update me’ button which takes them to a screen allowing them to edit
their address details. Once the new address details have been entered and saved, the screen which
allows them to check the shipping and billing addresses is presented again — this time with their
updated details displayed. After the customer verifies that the addresses are correct, they click on
the checkout option and a screen which requests credit card data is presented. The customer keys
in their credit card details and clicks on the confirm button. If the credit card number entered is
less than ten digits the order cannot be processed and an error message appears. If the credit card
number has been entered as a ten-digit number, the computer routes the credit card number and
billing address data to the bank, which verifies the card information and sends a message to the
computer indicating whether the payment has been successfully processed. Once the payment has
been verified, the customer is presented with a standard screen advising them that they have suc-
cessfully bought that day’s product.

10.33 Prepare a context diagram for receiving and recording a payment at Yayy Online. (LO4)
10.34 Prepare a process map for receiving and recording a payment at Yayy Online. (LO4)
10.35 Prepare a level 0 logical DFD for receiving and recording a payment at Yayy Online. (LO4)

476 PART 3 Systems in action

10.36 Prepare a physical DFD for receiving and recording a payment at Yayy Online. (LO4)
10.37 Prepare a systems flowchart for receiving and recording a payment at Yayy Online. (LO4)

The case narrative below (Jays Outdoors) will be used to complete problems 10.38–10.50. Make
sure you read and understand the activities and the case thoroughly before you commence work on
the problems.

Jays Outdoors revenue cycle

Jays Outdoors is a retail business selling outdoor entertainment goods such as tents, sleeping bags,
camping furniture, etc. In addition to having stores across Australia, Jays uses a website to sell goods
online. In order to buy, online customers must have previously registered and created a Jays customer
account with a unique username and password.

Process 1.0 Process the sales order

Customers log on to the Jays website using their registered username and password. The computer
checks that the username and password are valid. Customers with an invalid username and/or pass-
word are sent a message advising them that their login is invalid. Customers with a valid username and
password are presented with the current product catalogue. The customer browses the online catalogue
and creates an order by entering the quantity required in a check box beside each product they want
to purchase. After browsing and selecting all their products, the customer clicks an ‘order completed’
button. A total price is calculated for the goods selected based on quantity x price (a default sales
price is stored in the inventory data store). The computer identifies suitable shipping options and their
associated prices and presents these shipping options to the customer, along with the total price for
the selected products. The customer selects their preferred shipping option by checking the appropriate
tick box. The computer assigns the next sales order number from the sales order data store, updates
the inventory database to show that the products selected have been allocated to a sales order, then
calculates a total for the sales order including the selected shipping costs. The computer saves the
sales order in the sales order data store with a status ‘1’ (awaiting payment), then displays the sales
order total.

Process 2.0 Receive and record payment

The computer asks the customer to enter their credit card payment details, then sends a payment
validation request to the bank. On receipt of the payment request, the bank’s computer assesses
whether to approve or decline the payment request. The bank’s computer sends an approved or
declined notification to Jays computer. This process normally takes less than a minute. On receipt of
the notification from the bank, the computer changes the status to ‘2’ (paid and awaiting shipment).
Declined payments are uncommon, but if one is encountered the sales order status is changed to ‘9’
(cancelled), the inventory database is updated to show that the products are no longer allocated to
a sales order, and the customer is advised via email that their sales order has been cancelled due to
a declined payment. At 5 am each morning, the computer extracts any status ‘2’ (paid and awaiting
shipment) sales orders, changes the sales order status to ‘3’ (shipping underway) and then creates
two copies of a .pdf shipping notice for each sales order, which is emailed to the shipment manager
in the shipping department.

Process 3.0 Pick, pack and ship the goods

At 7 am daily, the warehouse officer collects the shipping notices from the shipping manager. Each
shipping notice label contains the customer name and address, and details of the items ordered by
the customer. The warehouse officer packs the individual items into a box and seals it. The warehouse
officer attaches one copy of the shipping label to the box and initials and dates the other copy. Once all
the packing has been completed, the warehouse officer calls Australia Post and asks them to come and
collect the goods. The warehouse officer leaves the packed goods on the delivery dock for the Australia
Post courier to collect. The warehouse officer gives the signed copies of the shipping notices to the
shipping manager. Before leaving for the day, the shipping manager enters the shipping notice number
into the computer and ticks a box that says ‘order complete’. The computer updates the sales order
status to ‘4’ (goods shipped).

CHAPTER 10 Transaction cycle — the revenue cycle 477

10.38 Prepare a context diagram for the revenue cycle at Jays Outdoors. (LO4)
10.39 Prepare a level 0 logical DFD for the revenue cycle at Jays Outdoors. (LO4)
10.40 Prepare a process map for: (LO4)
(a) process 1.0 at Jays Outdoors
(b) process 2.0 at Jays Outdoors
(c) process 3.0 at Jays Outdoors.
10.41 Prepare a level 1 logical DFD for: (LO4)
(a) process 1.0 at Jays Outdoors
(b) process 2.0 at Jays Outdoors
(c) process 3.0 at Jays Outdoors.
10.42 Prepare a physical DFD for: (LO4)
(a) process 1.0 at Jays Outdoors
(b) process 2.0 at Jays Outdoors
(c) process 3.0 at Jays Outdoors.
10.43 Prepare a systems flowchart for: (LO4)
(a) process 1.0 at Jays Outdoors
(b) process 2.0 at Jays Outdoors
(c) process 3.0 at Jays Outdoors.
10.44 Table 10.3 identifies 11 risks typically encountered when processing a sales order. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the sales process at Jays Outdoors.
(b) Determine how many of the common controls described in table 10.3 are present in the
sales process at Jays Outdoors.
(c) Prepare a short report suitable for senior management to explain how risky you think the
sales process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the sales
process at Jays Outdoors in order to reduce the level of risk.
10.45 Table 10.4 identifies eight risks typically encountered when despatching a sales order. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the goods despatch process at
Jays Outdoors.
(b) Determine how many of the common controls described in table 10.4 are present in the
goods despatch process at Jays Outdoors.
(c) Prepare a short report suitable for senior management to explain how risky you think the
goods despatch process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the goods
despatch process at Jays Outdoors in order to reduce the level of risk.
10.46 Table 10.6 identifies three risks typically encountered when receiving and recording
payments. (LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the receiving payments process at
Jays Outdoors.
(b) Determine how many of the common controls described in table 10.6 are present in the
receiving payments process at Jays Outdoors.
(c) Prepare a short report suitable for senior management to explain how risky you think the
receiving payments process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the receiving
payments process at Jays Outdoors in order to reduce the level of risk.
10.47 Jays Outdoors has adopted a cost leadership strategy. Its overall plan is to undercut competitors
on pricing and so gain market share.

478 PART 3 Systems in action

 (a) How well does its current revenue cycle align with this business strategy?
(b) Are there any opportunities to improve the degree of alignment between the revenue cycle
and the business strategy? Explain what you would change and how this would improve the
strategic alignment. (LO1)
10.48 (a) Identify and describe the technologies that Jays Outdoors uses in its revenue cycle
activities. (LO2)
(b) For each of those technologies you identified in part (a), how well does Jays Outdoors use
the technology? Could you suggest a way to improve the business benefit obtained by use
of any of these existing technologies?
(c) Are there other suitable technologies available that Jays Outdoors could be using for the
revenue cycle activities? What additional technologies could Jays Outdoors implement?
What business benefit would these additional technologies provide?
10.49 During process 3.0 Pick, pack and ship the goods at Jays Outdoors, a warehouse officer has
to decide which goods to pack for each customer. Take a moment to review this section of the
narrative before you complete the following questions. (LO3)
Required
(a)
What data does the shipping officer draw on when making the decision?
(b)
Where do the data you identified in part (a) come from?
(c)
Are these data reliable, that is, is there any possibility that there could be errors in the data?
(d)
Are these data sufficient to make the decision, or can you identify additional data that the
officer should consider when making the decision?
(e) What would be the consequences of an incorrect decision?
10.50 Explain how you would measure performance of the revenue cycle at Jays Outdoors,
specifically: (LO6)
(a) What metrics would you use to measure performance?
(b) For each metric, explain where you would obtain the data required for that metric.
(c) For each metric, explain why it is a good metric to help measure how well the revenue
cycle is meeting its objectives.

FURTHER READING
Brown, SA 1996, What customers value most: how to achieve business transformation by focusing on
processes that touch your customers: satisfied customers, increased revenue, improved profitability,
John Wiley & Sons Inc., New York.
Davenport, TH, Harris, JG, Jones, GL, Lemon, KN, Norton, D & McCallister, MB 2007, ‘The dark
side of customer analytics’, Harvard Business Review, May, vol. 85, no. 5, pp. 37–48.
Goldstein, D, Johnson, E, Herrmann, A & Heitmann, M 2008, ‘Nudge your customers toward better
choices’, Harvard Business Review, November, vol. 86, no. 12, pp. 99–105.

SELF-TEST ANSWERS
10.1 d, 10.2 b, 10.3 a, 10.4 c, 10.5 d, 10.6 d, 10.7 c, 10.8 d, 10.9 a, 10.10 b, 10.11 c

ENDNOTE
1. Possum IT 2009, ‘Café chain uses robust POS solution to improve productivity and customer satisfaction’, www.possumit.com.au.

CHAPTER 10 Transaction cycle — the revenue cycle 479

ACKNOWLEDGEMENTS
Figures 10.5, 10.6, 10.11, 10.15, 10.16, 10.17, 10.20, 10.23: Screen captures from Xero used with
permission. © Xero Limited and affiliates, 2015. Xero® and the Xero logo are registered trademark
of Xero Limited. Any data displayed in these images is fictitious, and any similarities with any actual
data, individual, or entity is purely coincidental.
Photo: © GlobalStock / iStockphoto.

480 PART 3 Systems in action

chapter 11

Transaction cycle —
the expenditure cycle
Lea rnin g Obje ctive s

After studying this chapter, you should be able to:

11.1 reflect on the key objectives and strategic implications of the expenditure cycle
11.2 evaluate common technologies underpinning the expenditure cycle
11.3 recognise expenditure cycle data and key expenditure business decisions
11.4 summarise and prepare documentation synthesising the primary activities in the expenditure cycle
and the data produced by these activities
11.5 assess risks and compose control plans pertinent to the primary activities in the expenditure cycle
11.6 justify metrics to monitor expenditure cycle performance.
Introduction
Expenditure-related activities are strategically and operationally important for all organisations. The expendi-
ture cycle commences when a section of the organisation signals a need for goods or services to be provided
and ends when the goods or services have been paid for. During the cycle, demand for requested goods or ser-
vices needs to be correctly established and any resulting purchase orders need to be accurate and appropriately
authorised. Delivered goods must be received in a timely fashion and both the quality and quantity of goods
delivered need to be checked before acceptance. Payments made to suppliers must be both timely and accurate.
This chapter commences with an overview of the expenditure cycle and then considers the strategic
implications of that cycle. Technologies that underpin the cycle are discussed and then the data produced
and consumed during the cycle activities are identified. Typical business process decisions are examined,
along with some of the primary considerations related to those decisions. An expenditure cycle is fully
documented using process maps, data flow diagrams (DFDs) and flowcharts, along with a set of tables
containing additional details to aid in understanding the process activities and the related risks and controls
of the activities. Finally, issues relating to measuring performance of the expenditure cycle are discussed
and examples of performance metrics suitable for measuring expenditure cycle performance are provided.

482 Part 3 Systems in action

11.1 Expenditure cycle overview and key objectives
LEARNING OBJECTIVE 11.1 Reflect on the key objectives and strategic implications of the expenditure cycle.
In order to achieve overall business objectives and remain profitable, the expenditure cycle needs to be
well designed and tightly controlled. Poorly controlled expenditure can lead to cash flow and liquidity
problems. An additional consideration for the expenditure cycle is the need to balance the supply and
demand for products within the organisation. The revenue cycle sales phase discussed in chapter 10
determines the demand for the goods and services provided by the company. The primary responsibility
of the expenditure cycle purchasing phase is to ensure the supply of goods balances this demand. The
organisational units most involved in the expenditure cycle are shown in figure 11.1.

Chief executive
officer

Director Director Director Director Director

administration finance or logistics marketing sales
accounting

Funds Inventory Sales order

Personnel Advertising
disbursement control processing

Office Customer
operations Billing Purchasing service

Tax planning Receiving

Maintain accounts
Storage
payable

Budgeting Production

Update accounting
Shipping
records

FIGURE 11.1 Organisational units in the expenditure cycle

Note: The dashed lines with the arrows show the business activities that each unit is responsible for.

Similarly to the revenue cycle described in chapter 10, the expenditure cycle is generally thought of
as two separate elements. The first of these is purchasing. This phase interacts extensively with external
suppliers of goods and services; the overall objective is to procure the right goods at the right amount,
and to receive those goods at the right time. In order to achieve this outcome, initiated purchases need
to be properly approved and authorised; goods and services need to be obtained from authorised or pre-
vetted suppliers; all purchase commitments and obligations need to be recorded accurately; and accepted
goods and services must meet quality and delivery specifications. Errors in the purchasing phase can
lead to a situation where goods are not available to meet customer needs if demand is underestimated, or
to the organisation incurring unnecessary inventory holding costs if demand is overestimated.

Chapter 11 Transaction cycle — the expenditure cycle 483

 Following the purchasing phase is the accounts payable phase, where the objective is to pay the right
people the right amount at the right time. The activities in this phase are typically conducted by back-­
office staff who will not necessarily have had previous contact with the suppliers of the goods. In order
to ensure ongoing good relationships with suppliers and minimise the risk of improper payments, it
is essential that all relevant information relating to the purchasing phase is shared with the accounts
payable phase. Additionally, the quality of the goods received, although not a data point conventionally
thought of as related to accounting, is a vital indicator when deciding whether a payment should be
made to a supplier. The accounts payable phase needs to ensure that payments are made by authorised
employees only, and that those payments are both accurate and timely, while ensuring that favourable
settlement terms are used to advantage. In order to ensure the integrity of financial reporting and finan-
cial statements, all accounts payable liabilities must be recorded accurately and promptly. A description
of documentation commonly used in the expenditure cycle is shown in table 11.1.

Strategic implications of the expenditure cycle

The expenditure cycle is strategically important to an organisation, particularly in terms of the degree of align-
ment with the overall business strategy. A sound, well-controlled expenditure cycle can provide a competitive
advantage by providing high-quality products and services, which in turn translates to an opportunity for higher
product pricing. An alternative form of competitive advantage is the potential to control costs that is afforded
by ensuring that the expenditure cycle is efficient and effective. This translates to an opportunity to provide
goods and services at a level that undercuts less efficient competitors and increases market share. An organ-
isation seeking to maintain or improve market share by using a cost leadership strategy (i.e. pricing its product
low enough to attract additional sales) will behave in a fundamentally different way to that of an organisation
seeking to differentiate its product in that same market. A key strategic alignment area within the purchasing
process relates to the selection and approval of suppliers of goods and services. A cost leadership strategy would
indicate that suppliers who can provide goods of suitable quality at a lower price should be selected, whereas a
differentiated strategy would be better served by selecting suppliers with high-quality products and good service
standards. Failure to correctly align this activity set with the overall strategy can invalidate strategic intent.

TABLE 11.1 List of source documents in the expenditure cycle

Documents Description

Purchase requisition Allows the requisitioning department to place an order for goods or services. The requisitioning
department or the inventory control section prepares the purchase requisition form. The
purchase requisition document is shared only within the organisation.
Purchase order Acts as evidence of purchase as well as a binding contract between the firm and the
vendor. The purchase order is prepared by the purchasing department. The purchase
order document is shared both within the organisation and externally.
Vendor list List of authorised vendors that offer quality goods and services at reasonable prices. The
vendor list is kept as part of the organisational database and is viewed and edited by the
business processes in the expenditure cycle.
Purchase invoice Details the amounts due and payment terms and conditions. This document is prepared
by the vendor.
Goods packing slip Generated by the vendor and attached with the goods sent to the purchasing organisation.
Receiving report Provides details of each delivery such as vendor details, shipping weight, corresponding
purchase order number and description of delivered goods. The receiving department
generates this report.
Remittance advice Used to notify the payee of the items being paid for. This document may be an invoice or
a stub attached to the payer’s cheque or other forms of notification. The remittance advice
can be prepared by both the accounting/finance unit and the vendor (in the case of a stub
that the vendor prepares).

484 Part 3 Systems in action

 In terms of the purchasing phase, failure to correctly manage purchasing can lead to systemic prob-
lems: an unreliable supply of goods and services has the potential to negatively impact the revenue,
production and inventory management processes. Buying too much, too little or the wrong items creates
inventory problems and can lead to increased costs or a decline in revenues. The accounts payable phase
involves cash leaving the business and, as a result, has a high potential exposure for fraud. Accounts pay-
able fraud often involves fictitious suppliers and false invoices, which requires collusion, inside knowl-
edge and access, whereas cash payments frauds are often less sophisticated but are becoming easier and
more common with computer duplication technology. Arranging and making payments creates an expo-
sure to potentially costly errors and mistakes, whereas poor payment practices can damage cash flow
and/or supplier relationships.

11.2 Technologies underpinning the

expenditure cycle
LEARNING OBJECTIVE 11.2 Evaluate common technologies underpinning the expenditure cycle.
There are a number of technologies suitable for supporting activities within the expenditure cycle and
improving the overall functioning of the process. A range of inventory management tools are avail-
able to help improve the ability to balance supply and demand for goods and services. Transparency
and management of cash payments and cash flows can also be improved by the use of appropriate
technologies.
Enterprise resource planning (ERP) systems assist with enabling and integrating the activities
within the expenditure cycle. The expenditure cycle links into many areas within the organisation, and
an ERP system can not only improve the integration of enterprise-wide data but also provide tighter link-
ages between relevant modules such as sales, production, accounts payable, cash budgeting and general
ledger. In essence, an ERP system acts to provide tighter connections between demand and supply func-
tions within the organisation.
The expenditure cycle can benefit greatly from technologies that provide an efficient means of data
exchange with suppliers of goods and services. Some of the ‘paperwork’ associated with the expenditure
cycle (e.g. purchase orders, purchase requisitions) originates in-house and is sent outwards to customers,
and the remainder is generated externally by suppliers (e.g. price quotes, invoices, delivery dockets).
Use of technologies such as electronic data interchange (EDI) can provide accurate, timely and
cost-effective data sharing.
The expenditure cycle involves many activities related to the physical handling and movement of
goods. Where volumes are sufficiently high to warrant the use of printed barcodes or radio frequency
identification (RFID) tags, hand-held scanning devices can cut stock handling and recording costs and
improve the accuracy and timeliness of inventory and expenditure data.
Specialised supply chain management software (SCM) can be used to improve both the planning
(identifying demand for products) and execution (receiving orders, routing goods) of the supply chain
by providing detailed supply chain analytics. SCM can be incorporated as an integrated module within
an existing ERP system, or acquired and operated independently using a best-of-breed supplier such as
Manhattan Associates or i2 Technologies.
The ability to make electronic payments provides a fast and comparatively inexpensive way for organ-
isations to settle their accounts with suppliers. When using electronic payment facilities such as those
provided by the major banks it is important to consider the timing and cash flow implications. A pay-
ment made electronically will take funds from a company bank account immediately, whereas a payment
made via cheque may take up to ten working days before any funds are withdrawn from the company
account. In addition to these payment timing issues, it is vital to consider and appropriately design
access security over online payment facilities.

Chapter 11 Transaction cycle — the expenditure cycle 485

 AIS focus 11.1

Getting behind the scenes — managing your supply chain

Australia’s retail sector is an enormous industry generating a turnover of $292 billion and employing over
1.2 million people. Underpinning the sector [are] its suppliers, who provide businesses [with the] suste-
nance to service their client base, generate revenue, and with some efficiency, make a profit.
The importance of a retailer’s supply chain cannot be understated. A team of Accenture, INSEAD and
Stanford University researchers has drawn statistical correlation between companies’ financial success
and the depth and sophistication of their supply chains (D’Avanzo, R et al. 2003, ‘The link between supply
chain and financial performance’, Van Wassenhove Supply Chain Management Review). According to
the research, companies with best practice supply chain management demonstrated a higher than
industry average growth rate. Maintaining an efficient supply chain goes well beyond keeping overheads
to a minimum. In a fiercely competitive retail market, customers have little tolerance for out-of-stock
items and long waits for products. With fewer loyal shoppers today, it only takes one bad experience to
send them and their money to the competition. More than ever, customers cannot be taken for granted
and it is critical to meet their demands through efficiencies in supply chain management.
Operating in a consumer-driven market and matching supply to demand is one of the key focuses of
supply chain management. The challenge for most retailers is servicing customer demands while not
overstocking products that are not in demand.
The proliferation of information and communications technologies (ICTs) has played an integral role in
increasing retail supply chain efficiencies. Bar code, radio frequency identification devices (RFIDs) and
remote sensors have all improved our ability to replenish stock, accurately measure movements from
end to end, assess a product’s success or failure and collaborate with our suppliers so that consumer
demands are met with as little wastage as possible. Technology alone will not be enough to achieve
these goals. Best practice supply chain management involves going beyond a company’s four walls.
Technologies facilitate these means to an end, but to achieve complete integration it is important all
partners in the supply chain are speaking the same language. The adoption of open global standards in
data integration has ensured companies can easily exchange information and conduct business without
unnecessary communication obstacles or bottlenecks.
An exemplary case of best practice supply chain management is European clothing manufacturer/
retailer Zara. Zara’s store managers constantly send customer feedback to in-house designers using
hand-held devices to inform them in real time of what is happening on the shop floor. Designers are
quickly able to ascertain which merchandise is moving and what should be culled, resulting in tighter
linkages between supply and demand and more efficient inventory management due to fewer unsellable
products being left on the shop floor or in the stock room. This together with a range of other supply
chain innovations during the manufacturing process enable Zara to deliver new styles to their stores in
three to six weeks, as opposed to the industry standard of five months.1
Source: Australian Retailers Association, www.retail.org.au.

11.3 Data and decisions in the expenditure cycle

LEARNING OBJECTIVE 11.3 Recognise expenditure cycle data and key expenditure business decisions.
A range of data are both produced and consumed by activities within the expenditure cycle. The actual
data stores are documented in detail later in this chapter. This section describes the general purpose and
types of data that the expenditure cycle requires. The business decisions made during the life of the
expenditure cycle are also discussed here.

Data and the expenditure cycle

Expenditure cycle activities require access to data related to inventory to help identify existing stock levels. In
order to correctly identify how much to purchase it is important to be familiar with both the current demand
for the goods (which comes from the sales process) and how much inventory is currently available for sale.
Expenditure cycle activities ultimately result in an increase in the amount of inventory on hand. Inventory data

486 Part 3 Systems in action

should ideally be updated regularly by expenditure activities to indicate the current status code of goods that
have been ordered but not yet received. Inventory data typically include many non-financial indicators, such as
quality of the goods received. There are also a number of dates of significance when analysing inventory and
supplier performance, such as date ordered, date confirmed, date expected and date delivered.
In addition to inventory data, the expenditure cycle requires access to data about suppliers, including
both basic name and address details and information about preferred suppliers, including past perfor-
mance. In terms of the data produced by expenditure activities, an organisation may store detailed data
related to both informal product requests and formal product requisitions. A third type of data created
is purchase order data, which records details of all open (incomplete) purchase orders, including the
current status of each of the items on the order. Goods receiving activities also produce goods received
data, which lists items received from suppliers and typically updates the inventory status of those goods.
Goods received data are also used to verify invoice validity during the accounts payable phase.
Accounts payable data are both created and updated by activities within the expenditure cycle;
invoices received from suppliers are recorded in accounts payable, as are details of payments made
during the accounts payable phase. More detailed information about payments made is recorded in the
cash payments data store.

Expenditure cycle business decisions

When the expenditure cycle is originally designed, or subsequently reviewed, a number of strategic
level decisions need to be made. These decisions are typically made by senior management within
the organisation and create the policy framework within which the cycle operates. To be effec-
tive, strategy-level business process decisions should be congruent with the overarching business
strategy. Strategy-level decisions would include creation of policies such as:
•• whether the organisation should consolidate purchases across units to obtain optimal prices — involves
a tradeoff between the flexibility afforded by decentralisation and the potential for economic gains
provided by centralised purchasing
•• how IT can be used to improve both the efficiency and the accuracy of the inbound logistics function
— the introduction of new technologies such as SCM may require considerable expense and incur
high risks. Dependent on product volumes and values of inventory items it may be difficult to cost-
justify a large technology implementation of this nature
•• identifying where inventories and supplies should be held — options include onsite warehousing in
either a centralised or decentralised format. An alternative solution is to set up a just-in-time (JIT)
supply chain under which goods are delivered only when they are required.
In addition to these strategy-level decisions, there are a range of operational-level decisions that will
be made every time the expenditure cycle is enacted. These operational decisions are typically made by
middle management or operational staff and relate only to a specific instance of the process. Figure 11.2
shows some example payments analytics used for decision making during the accounts payable phase.
Typical operational decisions include the following.
•• Determining the optimal level of inventory and supplies to carry — requires knowledge of previous
sales and/or some form of analysis of likely future sales, along with supplier data such as the lead
time to supply ordered goods. Also need to know current stock levels including numbers of the stock
on hand, stock already promised to customers and stock ordered but not yet delivered.
•• Deciding which suppliers provide the best quality and service at the best prices — often requires a
trade-off between price, quality and service. The weighting attached to each of these dimensions should be
determined by reference to the overall business strategy and to the type of product being procured.
•• Identifying if sufficient cash is available to take advantage of any discounts suppliers have offered —
requires knowledge of cash flow budgets and cash level predictions.
•• Determining how payment can be made to suppliers in order to maximise cash flow — payment
should be made when due and not before. Paying too early unnecessarily inhibits cash flows; paying
too late may alienate a supplier.

Chapter 11 Transaction cycle — the expenditure cycle 487

 Bills you need to pay

1 Draft bills 27,000.00

New bill
3 Awaiting payment 72,219.72
2 Overdue 57,100.00

Older 12-18 Jul This week 26 Jul–1 Aug 2–8 Aug Future

FIGURE 11.2 Payments analysis

Source: © Xero Limited.

AIS focus 11.2

Accounts payable processing at Telstra

Telstra is Australia’s leading telecommunications and internet services company. It employs more than
50  000 people in locations around the world. Regulation of the telecommunications market has loosened
over the past decades, with full competition introduced about 15 years ago. At about the same time, T­ elstra
began working on centralising its accounts payable processing as part of a broader move to achieve cost
efficiencies and at the same time better support suppliers. The centralisation of accounts payable saw
the process move from 60 separate sites to a single site. Telstra also improved productivity by introducing
­scanner-based technologies to eliminate the keying of data, which was seen as adding no value.
ReadSoft software was installed to process accounts payable payment authorisation forms. The
system handles about a quarter of a million accounts payable forms annually, but it is anticipated that
volumes will eventually increase to around 1.5 million forms per year as other processes take advantage
of the system.
The use of scanners offers several key advantages over keying in data.
1. Automating data input in this manner reduces the per transaction cost for accounts payable pro-
cessing. This is a highly valuable proposition in a high-volume environment such as Telstra.
2. Automating data means staff hours can be allocated to higher-value tasks such as handling
account disputes rather than to low-value data entry roles.
3. Automating data entry and data handling greatly reduces data transcription errors.
Source: Information from ReadSoft, www.readsoft.com.au.

11.4 Expenditure cycle documentation

LEARNING OBJECTIVE 11.4 Summarise and prepare documentation synthesising the primary activities
in the expenditure cycle and the data produced by these activities.
The expenditure cycle is documented in this section as a series of diagrams with increasing detail. An
overview of these expenditure cycle diagrams is shown in figure 11.3.

488 Part 3 Systems in action

 Context diagram Expenditure
– figure 11.4 cycle

Level 0 1.0
logical diagram 2.0 3.0 4.0
Determine demand
– figure 11.5 Order goods Receive goods Pay for goods
for goods

1.1 1.2 2.1 2.2 3.1 3.2 4.1 4.2

Collect Create Choose the Create the Accept the Record Approve the Make the
requests purchase supplier purchase delivery goods payment payment
requisition order received
Level 1 logical diagram – figure 11.7 Level 1 logical diagram – Level 1 logical diagram – Level 1 logical diagram –
Process map – figure 11.08 figure 11.12 figure 11.21 figure 11.27
Physical DFD – figure 11.30 Process map – figure 11.13 Process map – figure 11.22 Process map – figure 11.28
Flowchart – figure 11.31

FIGURE 11.3 Expenditure diagrams overview

Expenditure cycle context

The context diagram of a typical expenditure cycle is depicted in figure 11.4. The expenditure cycle
involves direct interaction with suppliers located outside the organisation. Within the organisation, the
expenditure cycle interacts with the production cycle, the inventory department and a range of miscel-
laneous departments, and the financial cycle as shown in figure P3.1. Details of the logical data flows
depicted in the expenditure context diagram are shown in table 11.2.

Supplier

(41)
(32)
(33) (49)
(31)

(46)
(16)

Expenditure
Financial
Inventory cycle
cycle
department (3)

(17) (52)

(1)
(18)
Misc. (2) Production
departments cycle

FIGURE 11.4 Expenditure cycle context diagram

Chapter 11 Transaction cycle — the expenditure cycle 489

 Expenditure cycle logical data flows
Figure 11.5 depicts a level 0 logical DFD. This diagram shows the entire expenditure cycle in greater
detail than that depicted in the context diagram. The logical DFD is an exploded version of the context
diagram, with the bubble described as ‘expenditure cycle’ in the context diagram broken down into
four processes. The logical diagram at level 0 helps to analyse and understand the expenditure cycle
in its entirety. It depicts the chronology of the cycle, the data stores and external entities involved in
each of the processes, and the interactions between these processes, entities and data stores. The logical
level 0 diagram in figure 11.5 is itself broken down to describe even lower levels of detail in figures 11.7,
11.12, 11.21 and 11.27. Details of the logical data flows depicted in this diagram are shown in table 11.2.
Description of logical data flows in the expenditure cycle
A logical DFD contains only those data flows relating to inputs and outputs of the activities contained
within each of the processes, as opposed to the details of all interactions between entities which are
depicted in a physical DFD. As a result, the number of flows in a logical DFD is always less than those
that would be shown in a physical DFD for the same process. To illustrate this, compare figures 11.7
and 11.30, which show exactly the same process; however, figure 11.7 is a logical description whereas
figure 11.30 is a physical description. To ensure completeness, all the data flows relating to the expendi-
ture cycle appear in table 11.2.

Table 11.2 Description of logical data flows in the expenditure cycle

Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

Process 1.0 Determine demand for goods

1 Production cycle Purchase Purchase request The production cycle requires raw materials in order
requisition officer to produce the finished goods; this data flow would
occur when additional raw materials are required.

2 Miscellaneous Purchase Purchase request These requests relate to the purchase of non-inventory
departments requisition officer or consumable items such as stationery.

3 Inventory Purchase Purchase request These requests relate to inventory items (i.e. items
department requisition officer that are purchased with the intention of reselling to
customers).

4 Purchase Purchase request Purchase request Requests are sometimes accumulated over a period of
requisition officer file time before an order is placed.

5 Purchase request Purchase Purchase request This data flow is showing the accumulated requests
file requisition officer being removed from the file and actioned.

6 Collect requests Create purchase Trigger for next After purchase requests are collected and
requisition process accumulated, a purchase requisition can be created
(not necessary in a level 0 diagram).

7 This flow takes place physically between the purchase requisition officer and the computer; it happens within
the 1.0 bubble in the logical diagram.

8 Inventory data Purchase Inventory levels Before a purchase requisition is created, the purchase
store requisition officer requisition officer should check existing stock records
to determine whether the requested item is currently
held in inventory, and how many of the item are
currently in stock.

9 Sales data store Purchase Prior sales history The purchase requisition officer may check the
requisition officer previous sales history for items requested as part of
the finished goods inventory.

490 Part 3 Systems in action

 Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

10, 11 These flows take place physically between the purchase requisition officer and the computer; they
happen within the 1.0 bubble in the logical diagram.

12 Purchase Computer Number of In order to allocate a sequential number the system

requisitions data last purchase needs to know the last number allocated so it can
store requisition raised increment that number by one.

13 Computer Purchase Purchase Once the purchase requisition has been created, a
requisition data requisition details record is written in the data store recording all the
store details of the requisition.

14 Computer Inventory details Purchase The amount of inventory included in the purchase
requisition details requisition is recorded in the inventory data store with
a status of ‘requisitioned’.

15 This flow takes places physically between the purchase requisition officer and the computer; it
happens within the 1.0 bubble in the logical diagram.

16 Purchase Inventory Purchase Details of the purchase requisition raised are

requisition officer department requisition details communicated back to the department that originally
requested the goods.

17 Purchase Miscellaneous Purchase Details of the purchase requisition raised are

requisition officer departments requisition details communicated back to the department that originally
requested the goods.

18 Purchase Production cycle Purchase Details of the purchase requisition raised are
requisition officer requisition details communicated back to the department that originally
requested the goods.

19 Purchase Purchase order Purchase Details of the purchase requisition are sent to the
requisition officer officer requisition details purchase officer so that a purchase order can be
created.

Process 2.0 Order goods

20 Supplier data Purchase order Supplier details Where authorised suppliers exist, the purchase order
store officer officer would obtain data relating to those suppliers to
help decide who to purchase from.

21 Choose supplier Create the Trigger for next Once the supplier has been chosen the purchase
purchase order process order can be created (not necessary in a level 0
diagram).

22 Purchase Purchase order Purchase Purchase requisition data such as product details and
requisition data officer requisition details quantity required are retrieved and used to create the
store purchase order.

23 Supplier data Purchase order Supplier details Supplier details such as name and address are
store officer retrieved for use in the purchase order.

24 Inventory data Purchase order Inventory details Inventory details such as the stock numbers and usual
store officer order quantities (i.e. each, dozen, pallet) are retrieved
for use in the purchase order.
(continued)

Chapter 11 Transaction cycle — the expenditure cycle 491

Table 11.2 (continued)

Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

25 Purchase order Purchase order Purchase order In order to allocate a sequential number the system
data store officer details needs to know the last number allocated so it can
increment that number by one.

26 Purchase order Purchase order Purchase order Details of the newly created purchase order are written
officer data store details into the purchase order data store.

27 Purchase order Purchase Purchase order The status of the purchase requisition is updated to
officer requisition data details ‘ordered’.
store

28 Purchase order Inventory data Purchase order The status of the inventory items is updated to
officer store details ‘ordered’.

29 Purchase order Warehouse staff Purchase order Details of the purchase order are forwarded to allow
officer details warehouse staff to anticipate receiving the goods.

30 Purchase order Accounts payable Purchase order Details of the purchase order are forwarded to the
officer details accounts payable officer to allow them to anticipate
paying for the goods once they have been received.

31 Purchase order Supplier Purchase order Details of the purchase order are forwarded to the
officer details supplier to confirm the order and ensure that they
correctly supply the goods required.

32 Supplier Purchase order Order An order acknowledgement should be received from

officer acknowledgement the supplier detailing the acceptance of the order and
details the likely delivery date.

Process 3.0 Receive goods

33 Supplier Goods receiving Delivery details The supplier sends the goods along with some
officer delivery documentation. The documentation should
contain details of the goods despatched (type,
quantities, number of cartons) and the purchase order
number that the goods relate to.

34 Accept delivery Record goods Trigger for next Once the goods have been accepted they can
received process be checked and the goods receipt recorded (not
necessary in a level 0 diagram).

35 Purchase order Goods receiving Purchase order Purchase order details are extracted for use in
data store officer details recording goods received.

36 Goods receiving Goods received Goods received Details of the goods received (date, product details,
officer data store details supplier details and related purchase order details) are
written into the goods received data store.

37 Goods receiving Supplier data Goods received Details of the goods received including quality of
officer store details goods and delivery timeliness data are written into the
supplier data store.

38 Goods receiving Purchase order Goods received The purchase order status is updated to ‘goods
officer data store details received’.

492 Part 3 Systems in action

 Typical Typical
Flow # data source data destination Data description Explanation of the logical data flow

39 Goods receiving Inventory data Goods received The inventory status for the relevant product is
officer store details updated to ‘goods received’.

40 Goods receiving Accounts payable Goods received Details of the receipt of the goods are sent to the
officer details accounts payable section to facilitate processing of
payment to the supplier.

Process 4.0 Pay for goods

41 Supplier Accounts payable Invoice details An invoice, which is a request for payment for the
officer goods supplied, is received from the supplier.

42 Purchase order Accounts payable Purchase order Details of the purchase order are extracted and used
data store officer details to check that the details of the invoice are correct.

43 Goods received Accounts payable Goods received Details of the goods received order are extracted
data store officer details and used to check that the details of the invoice are
correct. Processing should only continue if the details
of the purchase order, goods received and invoice all
agree.

44 Supplier data Accounts payable Supplier details Details of the supplier (name, address and payment
store officer terms) are extracted for use in making the payment.

45 Accounts Accounts payable Payment details Details of the approved payment (due date, amount,
payable officer data store supplier and invoice details) are written into the
accounts payable data store.

46 Accounts Financial cycle Payment details The data relating to payments approved, which is
payable officer contained in the accounts payable data store, is
transferred to the financial cycle, where it is used to
update general ledger accounts.

47 Approve Make payment Trigger for next Once the payment has been approved the payment
payment process can be made (not necessary in a level 0 diagram).

48 Accounts Accounts payable Payment details On the due date established in the previous process a
payable data officer payment is generated.
store

49 Accounts Supplier Payment details The payment is sent to the supplier.

payable officer

50 Accounts Accounts payable Payment details Summarised details of the payment made are written
payable officer data store to the accounts payable data store.

51 Accounts Cash payment Payment details Full details of the payment made are written to the
payable officer data store cash payments data store.

52 Accounts Financial cycle Cash payment The data relating to the payment made, which is
payable officer details contained in the accounts payable data store, is
transferred to the financial cycle, where it is used to
update general ledger accounts.

Chapter 11 Transaction cycle — the expenditure cycle 493

 Misc.
departments

Inventory
(17) department
(2)
(3)
Production
cycle (18) (16)
1.0
Determine
(1) (13)
demand (12)
for goods
(4) (14)
(8)
(5) (9)

Purchase
(19) Inventory
Purchase requisitions
Sales
requests
(24)
(28)
(22)
(27)
2.0
(20)
Order goods
(23)
(26)
(25)
Suppliers (31)
(32) (30)
(29)
Supplier
Purchase
order
(37) (33)

(39) 3.0 (38)

Receive
goods (42) Financial
Inventory (46) cycle
(36) (35)

Goods
(40) (52)
received
4.0
(43) Pay for goods (49)
(44)
(41)

(51) Supplier
(48)
(50)
(45)

Cash Accounts
payments payable

FIGURE 11.5 Expenditure cycle level 0 logical diagram

494 Part 3 Systems in action

11.5 Expenditure cycle activities and related risks
and controls
LEARNING OBJECTIVE 11.5 Assess risks and compose control plans pertinent to the primary activities
in the expenditure cycle.
The activities within the expenditure cycle and the associated risks and controls are described under the
four expenditure process headings below. Following the activity descriptions for each of the processes
are the process map and level 1 DFD for the process and a table summarising the activities, risks and
controls within the process.

Determine demand for goods — activities, risks and controls

Process 1.0, determine demand for goods, comprises the following activities.
Collect requests
The expenditure cycle commences when a request is received to purchase goods or services. These
requests come from a number of places within the organisation, including the warehouse which may
request items required for inventory. Inventory items are purchased with the intention of reselling to
customers and are also known as finished goods inventory. Inventory purchase requests may be paper
or electronic, and could be triggered by reaching an automatic reorder point in the inventory system.
Automatic reorder points are based on predefined minimum inventory levels recorded for individual
items; when the stock on hand drops down to this level a purchase requisition is automatically generated.
The production cycle may request the purchase of raw materials required for production. This request
would occur when additional or different raw materials are required, and may be either electronic or paper.
Raw material requests from production may be automatically generated by production control software,
or created manually by production staff. The trigger for an automated request would be a reorder point
embedded in the production system that operates in a similar manner to the inventory reorder described
above and produces a request to purchase raw materials identified as being required for production of goods.
Other requests commonly received relate to the purchase of non-inventory or consumable items used in the
day-to-day running of the business, such as stationery. These requests could be paper or electronic, and may be
triggered by some internal stocktaking process for items such as stationery, or could be ad hoc for other, less
predictable consumables such as travel or catering. Due to the heightened risk of fraud or errors related to ad hoc
requests, they should be carefully scrutinised to ensure that requests are valid and approved before processing.
Purchasing staff may elect to hold requests for processing until an economically viable order quantity is
reached. The purpose of accumulating requests is so that economies of scale can be gained. This accumulation
should take place where there is a potential to achieve a better price outcome by buying in bulk, or where trans-
action costs can be lowered by a smaller number of larger orders. Requests would not be accumulated where
time is critical for the items being purchased. If accumulation is practised, then requests will need to be filed
temporarily until sufficient quantities of requests accumulate. It is important to establish a mechanism to ensure
any requests held in this way are not forgotten. The trigger for actioning accumulated requests could be tem-
poral, such as a particular day of the month, or could be triggered by the receipt of a similar purchase request.
Create purchase requisition
After purchase requests have been received and, if necessary, accumulated, a purchase requisition can be
created. An example of a purchase requisition is shown in figure 11.6. Note that this responsibility may
be devolved and undertaken within the initiating department, rather than being centralised within the pur-
chasing function as documented here. A purchase requisition is a document that is used internally only; it
is simply a request from one section of the organisation to another asking for goods to be ordered. Before
the purchase requisition is created, existing stock records should be checked to determine whether the item
requested is currently held in inventory, and how many of the item are currently in stock. This control is par-
ticularly important if purchase requests are made manually, as there is a possibility that the person raising the
request may not have checked stock records prior to requesting the goods. This inventory check would not be
necessary where the purchase request was generated automatically by an automatic reorder function.

Chapter 11 Transaction cycle — the expenditure cycle 495

 Australian Information Company
Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Purchase requisition form No: 936

Prepared by:
Data prepared: Date required:
Joseph Smith,
15/07/15 30/07/15
Purchasing Department

Contact person:
Suggested vendor: Deliver to:
Jill Darci,
Tech Supplies Delivery Dock
Purchasing Department

Item no. Description Quantity Price/unit

35930 Willow Series W laptop computer 1 $3500.00

93948 Hume Premier paper, 10 reams 15 boxes $  12.00

83748 Hyth HD diskettes, box of 10 15 boxes $   7.50

FIGURE 11.6 Sample purchase requisition form

The sales history for items requested may also be checked; prior sales history is useful to determine
sales volume and patterns, which helps decide whether the request seems reasonable. If there are mul-
tiple requests received from different divisions, prior sales data can also help to determine the optimal
economic ordering quantity.
Purchasing requisition staff should obtain approval from a more senior staff member before creating a pur-
chase requisition. Purchase requisitions can be created either electronically or manually. A manual purchase
requisition would be created by filling in a form (similar to the one in figure 11.6), having it authorised, and
sending a copy to the purchasing office. For an electronic version, a new record is written in the purchase
requisition data store recording all the details of the requisition. Documents such as purchase requisitions are
often pre-numbered so that the organisation is able to ensure that all documents are processed. Pre-numbered
documents are issued with a sequential number to allow clearer identification and better tracking of each docu-
ment issued. In order to allocate a sequential number electronically, the system needs to know the last number
allocated, so it can increment that number (usually by one) to assign a number to the new purchase requisition.
Once the purchase requisition has been created, the inventory record should be updated to show details
of the goods on the purchase requisition. The amount of inventory included in the purchase requisition
is recorded in the inventory data store with a status of ‘requisitioned’. This is particularly important
when predetermined reorder points are used, as failure to record this status could result in an item being
repeatedly requested, creating overstock problems.
The purchase requisition details should be communicated to the department that originally requested
the goods, to advise them that the goods have been requisitioned. This may happen electronically, in
which case an automated message would be generated directly from the computer once the purchase
requisition has been created.
The purchase requisition also needs to be sent to purchasing staff so a purchase order can be raised for
the goods requisitioned. This may happen electronically, in which case a message would be generated
directly from the computer, or manually, where a copy of the completed purchase requisition form is
sent via an internal mail system or delivered by hand.
The major risks related to creating a purchase requisition are requesting unnecessary items and under-
or overestimating requirements. Although the requisition is only used internally as a precursor to cre-
ating a purchase order, it is important not to rely solely on the controls embedded within the purchase
order process. That is, it is important to independently review and approve all requisitions generated.

496 Part 3 Systems in action

In particular, validity checks should be carried out for requests related to expensive or unusual items.
Note that adequate controls are necessary in the sales process to achieve accurate and complete sales and
inventory records and accurately determine demand. If there are flaws in the sales and/or inventory data,
demand will be incorrectly calculated and erroneous purchase requisitions may be raised. Exception
reporting and monitoring of stock-outs and/or obsolete goods will help reduce this risk.
Determine demand for goods — DFD
The level 1 DFD in figure 11.7 contains a lower level of detail about the first process represented in the
level 0 logical DFD in figure 11.5. In the same way in which the level 0 logical diagram explodes out
the ‘expenditure cycle’ bubble in the context diagram, the level 1 diagram explodes out the ‘determine
demand for goods’ bubble.
Summary description of activities in determining demand for goods
Table 11.3 summarises the activities, risks and controls when determining the demand for goods, as depicted
in the logical DFD in figure 11.7 and process map in figure 11.8. Table 11.2 explains the logical data flows
depicted in the DFD in figure 11.7 and the process map in figure 11.8. Exploring the diagrams in conjunction
with the material contained in the tables will assist with improving your understanding of the process depicted.

(1) (4)
Purchase
requests
Production
cycle
1.1
(2) (5)
Collect
requests

(3) Purchase
requisitions
Misc.
departments Inventory (6)
department
(13)
(12)
(14)
(16)
1.2
(8)
(17) Create
purchase
requisition
(18) (9) Inventory

Sales
(19)

2.0
Order goods

FIGURE 11.7 Expenditure cycle level 1 logical diagram — process 1.0 Determine demand for goods

Chapter 11 Transaction cycle — the expenditure cycle 497

 Receives
Production Requests raw purchase
materials requisition
details

Receives
Misc. Requests purchase
departments consumables requisition
details

Receives
Requests
Inventory purchase
inventory
department requisition
items
details

Requests Receives
Receives and Do we
Purchase Items in purchase purchase
accumulates sell item?
requisition officer stock? requisition requisition
requests
creation details

Receives
purchase
Purchase order
requisition
officer
details

Creates
Computer
purchase
requisition

FIGURE 11.8 Expenditure cycle process map — process 1.0 Determine demand for goods

TABLE 11.3 Activities in determining demand for goods

Usually Typical
Activity # Activity conducted by Activity description risks encountered Common controls

1.1 Collect Purchase The purchase requisition officer Under/over- Exception reporting
requests requisition receives requests for consumables estimating and monitoring of
officer and inventory items from a number requirements stock-outs and/or
of different departments within the obsolete goods
organisation. Separating review
The purchase requisition officer should and approval
obtain approval from a more senior of requisitions
staff member before creating the generated
purchase requisition.

1.2 Create Purchase Once the request is ready to be Requesting As above plus
purchase requisition actioned a purchase requisition is unnecessary items validity checks
requisition officer created. on large dollar
or unusual items

498 Part 3 Systems in action

Order goods — activities, risks and controls
Process 2.0, order goods, comprises the following activities.
Choose the supplier
When the purchasing department receives a completed and authorised purchase requisition, the first
task is to decide who to order the requisitioned goods from. Some organisations will have a list of
pre-approved or authorised suppliers to choose from for various products. This list should ideally
be created and maintained by someone who has no direct responsibility for placing purchase orders,
to reduce the risk of collusion and fraud. Where an authorised supplier list exists, purchasing staff
should access and assess the supplier data to help decide who to purchase from. During the search for
a suitable supplier, many organisations require purchasing staff to obtain price quotes from a given
number of suppliers (often three supplier quotes are required) in order to establish that they are not
paying too much for the goods. In addition to this competitive tendering process, the risk of paying
too much for goods can also be controlled by using pre-negotiated prices, and by using only pre-
approved suppliers. Expenditure budgets are also an important control; purchasing staff procure goods
on behalf of other departments, so a regular review of budget variances or one-by-one checking of
expenditure transactions should assist in identifying any significant overspends. In addition to paying
too much, there is a risk that poor-quality goods will be purchased. Common inventory quality con-
trols include using only pre-approved suppliers, conducting ongoing monitoring of supplier perfor-
mance and undertaking inventory quality checks. Policies relating to the timely termination of supply
contracts or removal of substandard suppliers from approved lists should also be in place; compliance
with these policies should be audited regularly.
Supplier performance is not solely financial: supplier data files should also contain non-financial
information related to delivery and service standards such as on-time delivery history, service request
response times and after-sales contacts. If no supplier list exists, purchasing staff will need to search the
market and determine a suitable supplier. Supplier suitability parameters will differ based on the product
requested. As an example, procuring reams of photocopy paper requires a totally different analysis to
purchasing a motor vehicle or a computer component. The choice of suitable suppliers is vital for the
organisation: inferior quality goods or late deliveries can cause loss of sales or delays in production.
The risk of purchasing from unauthorised suppliers can be reduced by ensuring appropriate approval
is received for all purchase orders, enforcing independent maintenance of supplier data and using pre-
approved suppliers. A common risk in this area is that of purchasing staff receiving kickbacks or secret
commissions or inducements from suppliers. To control for these risks, the organisation should create
and enforce policies relating to acceptance of corporate gifts and require disclosure of any contracts
where a conflict of interest exists, or the transaction is not conducted at arm’s length. Using personnel
policies such as job rotation and enforced annual leave help ensure that an individual does not maintain
sole power over a supplier relationship. Supplier audits may also be considered, particularly if product
quality appears to be an issue.
Controls and restrictions on corporate credit cards, where used, are also important. Corporate cards
are often used for ad hoc purchasing. Where they are used, an organisation may wish to restrict pur-
chases to certain dollar limits, or to certain organisations. Most organisations that issue corporate
credit cards insist that the cardholder retains all receipts, regularly reconciles, or acquits, the charges
on their card against those receipts, and forwards the reconciliation for independent audit and
approval.
Create the purchase order
After a suitable supplier has been identified, and the choice of supplier authorised, the purchase order
can be created. A purchase order can be either paper or electronic. A paper purchase order example
is shown in figure 11.9. Figure 11.10 shows an example of a screen used to input an electronic pur-
chase order. The purchase order is distributed to a number of departments within the organisation, and
externally to the supplier. A purchase order creates a commitment to buy and pay for the goods, so

Chapter 11 Transaction cycle — the expenditure cycle 499

the ability to create a purchase order, and any stocks of blank purchase order forms, should be closely
controlled. The purchase order is created based on purchase requisition data such as the product details
and quantity required. Supplier details such as name and address, and inventory details such as the stock
numbers and usual order quantities (e.g. each, dozen, pallet) are also used when creating a purchase
order. Purchase orders should always be pre-numbered so that the organisation is able to ensure that all
documents have been processed and to track every document issued. In order to allocate a sequential
number, the system needs to know the last purchase order number allocated, so it can increment that
number, usually by one.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Purchase order form No: 1245

To: Tech Supplies (Vendor Ref: 2839)

782 Mount Macedon Terrace
Victoria 3547

Order date: Delivery date: Purchase requisition no.:

17/07/15 26/07/15 936

Shipping via: Other remarks:

FOB: Destination Terms: 2/10, n/30
Calmex Logistics

Approved by: Contact person:

Item no. Description Quantity Price/unit

35930 Willow Series W laptop computer 1 $3500.00

93948 Hume Premier paper, 10 reams 1 15 boxes $12.00

83748 Hyth HD diskettes, box of 10 1 15 boxes    $7.50

FIGURE 11.9 Sample purchase order form

The details of the newly created purchase order are written into the purchase order data store and
the status of the purchase requisition should be updated to ‘ordered’. This helps to ensure that the
purchase requisition staff are aware that the goods requested have been ordered so that they can
factor this into any subsequent requisition calculations. At the same time, the status of the inven-
tory items ordered should be updated to ‘ordered’. This status update allows accurate forecasting
of future stock levels. Details of the purchase order should be forwarded to the warehouse to allow
staff to anticipate receiving the goods. The copy of the purchase order sent to the warehouse may be
a ‘blind’ copy (called a blind purchase order) with the quantity ordered obscured. Obscuring quan-
tities ordered forces goods receiving staff to count goods when completing a receiving report, rather
than simply being able to tick off a list. The details of the purchase order should also be forwarded to
the accounts payable staff to allow them to pay for the goods once they have been received. Finally,

500 Part 3 Systems in action

details of the purchase order are forwarded to the supplier to confirm the order and ensure that they
correctly supply the goods required. The example of a purchase order history screen in figure 11.11
shows open (undelivered) purchase orders. An order acknowledgement should be received from the
supplier detailing the acceptance of the order and the likely delivery date. This confirms that the sup-
plier has the goods available and is able to deliver them in accordance with the terms and conditions
contained in the purchase order.

L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases › Purchase Orders ›

New Purchase Order

Create

Contact Date Delivery Date Order number Reference

Hocking Sports Supplies 20 Jul 2015 27 Jul 2015 PO-0005

AUD Australian Dollar Amounts are Tax Exclusive

Item Description Quantity Unit price Disc% Account Tax rate Amount AUD

BMX: Mongoose Mongoose BMX Bike 15.00 216.00 630 - Inventory GST on 3,240.00
BMX Expenses

Road: Samson Samson Road Bike 20.00 430.00 630 - Inventory GST on 8,600.00
Road Bike Expenses

Add a new line Subtotal 11,840.00

Total GST 10.00% 1,184.00

Total 13,024.00

Delivery Address

Postal Attention Delivery instructions 500

985 Nicholson St
FITZROY NORTH
VIC
3068 Telephone
Australia

Save Approve Cancel

FIGURE 11.10 Purchase order screen

Source: © Xero Limited.

Chapter 11 Transaction cycle — the expenditure cycle 501

 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases ›

Purchase Orders

+ New Purchase Order

All Draft (0) Awaiting Approval (2) Approved (1) Billed (1)

4 items Search

Number Reference Supplier Date raised Delivery date Amount Status Sent

Awaiting
PO-0004 Crawford Cycle Wholesale 20 Jul 2015 27 Jul 2015 2,376.00
Approval

PO-0001 Clifton Bikes 20 Jul 2015 24 Jul 2015 15,120.00 Billed

Awaiting
PO-0003 Clifton Bikes 24 Jun 2015 1 Jul 2015 26,840.00
Approval

PO-0002 Clifton Bikes 1 Jun 2015 8 Jun 2015 10,560.00 Approved

FIGURE 11.11 Open purchase orders

Source: © Xero Limited.

Order goods — DFD

The level 1 DFD in figure 11.13 contains a lower level of detail about the second process represented
in the level 0 logical DFD in figure 11.5. This process takes place after the demand for goods has been
determined in the preceding process and before the goods are received in the following process.

Summary description of activities in ordering the goods

Table 11.4 summarises the activities, risks and controls when ordering goods, as depicted in the logical
DFD in figure 11.12 and process map in figure 11.13. Table 11.2 explains the logical data flows depicted
in figures 11.12 and 11.13. Exploring the diagrams in conjunction with the material contained in the
tables will assist in improving your understanding of the process depicted.

502 Part 3 Systems in action

 1.0
Determine
demand
for goods

(19)

2.1
Choose the (20)
supplier
Purchase
requisition
Supplier

( 21 )
(22) (23)

(28)
(24)
(27) 2.2
Create the
purchase
order (26)
(31) Inventory

(25)
Supplier (32)
(29) (30)
Purchase
order

3.0 4.0
Receive goods Pay for goods

FIGURE 11.12 Expenditure cycle level 1 logical diagram — process 2.0 Order goods

Chapter 11 Transaction cycle — the expenditure cycle 503

 Receives
Requests Receives
Requests Selects purchase order
purchase order purchase order
Purchase order supplier details supplier acceptance
creation details
officer advice

Computer Provides Creates

supplier details purchase order

Receives
Warehouse staff purchase order
details

Receives
Accounts payable purchase order
officer details

Receives Advises
Supplier
purchase order purchase order
details acceptance

FIGURE 11.13 Expenditure cycle process map — process 2.0 Order goods

TABLE 11.4 Activities in ordering goods

Usually Typical risks
Activity # Activity conducted by Activity description encountered Common controls
2.1 Choose the Purchase The purchase officer Purchasing Approval of purchase orders
supplier officer decides who to order from Independent maintenance of supplier data
the requisitioned unauthorised
Restrictions on corporate credit card use
goods from. suppliers
Using pre-approved suppliers
Paying too Price lists
much Approval of purchase orders (see example
in figure 11.14)
Competitive tendering
Budgets
2.2 Create the Purchase Once a supplier has Buying poor Using pre-approved suppliers
purchase officer been selected, the quality goods Ongoing monitoring of supplier
order purchase officer performance
creates a purchase
Inventory quality checks
order.
Kickbacks Corporate gift policies
Job rotation
Enforced annual leave
Supplier audits
Disclosure requirements (conflict of
interest, not at arm’s length)

504 Part 3 Systems in action

 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases › Purchase Orders ›

Edit Purchase Order PO-0004

Awaiting Approval Send Print Options

Contact Date Delivery Date Order number Reference

Crawford Cycle Wholesale 20 Jul 2015 27 Jul 2015 PO-0004

AUD Australia Dollar Amount are Tax Exclusive

Item Description Quantity Unit price Disc% Account Tax rate Amount AUD

BMX: Mongoose Mongoose BMX Bike 10.00 216.00 630 - Inventory GST on 2,160.00
BMX Expenses

Add a new line Subtotal 2,160.00

Total GST 10.00% 216.00

Total 2,376.00

Delivery Address

Postal Attention Delivery instructions 500

985 Nicholson St
FITZROY NORTH
VIC
3068 Telephone
Australia

Save Approve Cancel

FIGURE 11.14 Internal control — screen showing approval for purchase orders
Source: © Xero Limited.

Receive goods — activities, risks and controls

Process 3.0, receive goods, comprises the following activities.
Accept the delivery
The supplier sends the goods ordered accompanied by some delivery documentation. An example of a
goods delivery slip is shown in figure 11.15.
The delivery documentation should contain details of the goods despatched (type, quantities, number
of cartons) and the purchase order number that the goods relate to. Delivery may be made by the sup-
plier’s employees, or by a third-party courier company. The most important control consideration here is
the need to check the goods thoroughly before accepting the delivery. That is, the goods must be checked
prior to signing any delivery documentation and before the delivery driver departs. There are two impor-
tant checks to be carried out.

Chapter 11 Transaction cycle — the expenditure cycle 505

 First, goods receiving staff should check that there was a purchase order placed for the goods.
Receiving staff need to verify that the purchase order number is valid, that the goods and supplier listed
on the purchase order approximate those on the delivery documentation, and that the goods listed on that
purchase order have not been received already (to check against the possibility of incorrect or double
deliveries). Second, once it has been established that a valid purchase order exists, goods receiving staff
should carefully check the goods to ensure they are not damaged, and that the quantity of goods deliv-
ered is correct.

782 Mount Macedon Terrace

Tech Supplies Victoria
Packing Slip 3547

To: Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Packing slip no.: Delivery date: Purchase order no.:

P03-0939 26/07/15 AIC-1245

Item no. Description Quantity

35930 Willow Series W laptop computer 1

93948 Hume Premier paper, 10 reams 15 boxes

83748 Hyth HD diskettes, box of 10 15 boxes

Remarks:

FIGURE 11.15 Sample goods packing slip

The types of counts and checks conducted will vary depending on the volume and value of goods
received. Receiving a small number of high-value items would require careful checking of the quality
of each item, and that the item is exactly as indicated on the purchase order. Receiving a large
number of low-value items might require scrutinising the cartons for any obvious damage, and then
counting the number of cartons. For large-volume deliveries there is always a decision to be made as
to whether it is cost effective to actually open cartons and count individual goods. A more detailed
count should take place where individual item values are high, or if there is some doubt as to the
correctness of the volume claims made on the carton labels. If counting is being conducted manually,
it is necessary to introduce some controls against the risk of errors when counting goods received.
These controls could include providing some incentives for accuracy to motivate receiving staff
appropriately, or conducting a double-check of the count (but only where this is cost effective). As
mentioned above, many organisations use a blind copy of the purchase order for goods receipts; this
copy of the purchase order does not contain any quantities for the items ordered, forcing receiving
staff to physically count the goods.
The activities of checking purchase order details and counting the goods may be conducted using
a handheld scanner. This is a highly effective practice; use of handheld scanners not only improves
efficiency, it also increases data quality and timeliness. In order to use a handheld scanner, both
the goods and the delivery advice must contain a printed barcode, as shown in the example in
figure 11.16.

506 Part 3 Systems in action

 FIGURE 11.16 Example of a printed barcode

When using a scanner, receiving staff scan the barcode printed on the delivery docket to obtain infor-
mation about the related purchase order. Information is retrieved from the purchase order data store using the
scanned data to locate the relevant purchase order. Once the purchase order has been verified, the goods are
scanned to record their individual receipt. It is important to note that, although data accuracy is improved by
removing the need to manually record goods received, 100 per cent accuracy is not guaranteed. For example,
a carton may not be scanned, or it may be scanned twice. Further, there is no guarantee that the contents of a
carton match the barcode unless the carton is opened and the goods are visually checked.
An alternative form of scanning device reads an RFID tag. An example is shown in figure 11.17. The pri-
mary advantage of an RFID tag is that it can be scanned from a greater distance than a barcode, and it can
have new data about the item added to it, uniquely identifying the item and its current location and status.
Large-scale scanning of items containing RFID tags can be automated by building a scanner-equipped
gateway through which parcels are moved and scanned automatically. This method of scanning reduces the
need to manually locate and scan each item individually, reducing both labour costs and errors.

FIGURE 11.17 Example RFID tag

Once all the receiving checks have taken place, goods receiving staff should sign the delivery docket
to indicate that the delivery has been accepted. Most delivery documentation consists of two copies. One
copy should be retained by the receiver, the other copy should be signed and returned to the delivery
driver. To reduce the risk of theft of inventory, goods should be relocated immediately into a secure

Chapter 11 Transaction cycle — the expenditure cycle 507

storage place once the delivery has been checked and accepted. Additional controls to guard against this
risk include implementing physical controls, limiting access to the warehouse and conducting periodic
inventory counts. Segregation of duties is also important; in particular, goods should be received by a
staff member who is not able to order or request goods to be purchased, or to subsequently arrange the
despatch of those goods. For organisations that operate at multiple locations, it is important to ensure
that any internal transfers of inventory are correctly documented. Failure to document internal transfers
will lead to inaccurate inventory records at both locations and increase the risk of inventory theft.
Record goods received
Goods-receiving staff need to record the details of the goods received. This may take place manually by
writing the quantities of goods on a copy of the purchase order to create a receiving report. An example
of a manual receiving report is shown in figure 11.18. Figure 11.19 displays an example of electronic
goods receipting. Alternatively, the goods received data collection may be computerised, in which case the
receiving staff would enter data into the computer either by typing it in or using a barcode or RFID scanner
as described above. For either method it is important to accurately identify any variance between the goods
ordered and the goods received. If goods receiving is computerised, the use of data input edit checks to
identify variances at input stage, or automatic generation of any exception reports, should be considered.
The details of the goods received (date, product details, supplier details and related purchase order details)
are written into the goods received data store and the status of the related purchase order should be updated
to ‘goods received’. The inventory status for the relevant product should also be updated to ‘goods received’
to ensure accuracy of inventory records. Details of the goods received data often include the quality of the
goods and the delivery timeliness. This data is usually written into the supplier data store in order to be able to
maintain control over the quality of suppliers selected for future purchases. Details of the receipt of the goods
should also be sent to the accounts payable section to facilitate processing of the payment to the supplier.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Receiving report No: 1342

Order received: Purchase order no.:

26/07/15 1245

Shipper: Shipping weight: No. of packages:

Calmax Couriers 15 kg 3

Freight bill no.: Freight charges: Consignment?

— NIL Yes

Received and checked by: Delivered by:

Item no. Description Quantity Condition

35930 Willow Series W laptop computer 1 Good

93948 Hume Premier paper, 10 reams 15 boxes See below

83748 Hyth HD diskettes, box of 10 15 boxes Good

Remarks:
Hume Premier paper: One ream’s cover is torn, with paint on the top sheet. One ream will be replaced. So only
14 copies of Hume Premier paper are received.

FIGURE 11.18 Sample receiving report

508 Part 3 Systems in action

Inventory ›
Mongoose BMX

Edit item Options

Mongoose BMX
BMX Quantity on Hand

Inventory Item 95
Inventory Asset Account Inventory Asset Account
Average Cost

Purchases 196.36
Unit Price 216.00
Total Value
Cost of Goods Sold Account 310 - Cost of Goods Sold
18,654.29
Tax Rate GST on Expenses

Description Mongoose BMX Bike

In Committed Quotes

Sales 0

Unit Price 280.00

Quantity on Order
Account 200 - Sales
0
Tax Rate GST on Income

Description Mongoose BMX Bike

Recent Transactions

Date Type Reference Quantity Unit Price Total

20 Jul 2015 Bill PO-0001 +70 196.36 13,745.20

10 Jun 2015 Bill Hocking Sports Supplies +25 19.36 4,909.09

FIGURE 11.19 Goods received details

Source: © Xero Limited.

Receive goods — DFD

The level 1 DFD in figure 11.21 contains a lower level of detail about the third process represented in the
level 0 logical DFD in figure 11.5. This process takes place after the goods have been ordered from the
supplier in the preceding process and before payment is made in the following process.

Summary description of activities in receiving

the goods
Table 11.5 summarises the activities, risks and controls when receiving goods, as depicted in the logical
DFD in figure 11.21 and process map in figure 11.22. Table 11.2 explains the logical data flows depicted
in figures 11.21 and 11.22. Exploring the diagrams in conjunction with the material contained in the
tables will assist in improving your understanding of the process depicted.

Chapter 11 Transaction cycle — the expenditure cycle 509

TABLE 11.5 Activities in receiving goods
Usually Typical risks
Activity # Activity conducted by Activity description encountered Common controls
3.1 Accept Goods The goods receiving officer Receiving Checking the existence of a
the receiving officer decides if the goods can be unordered purchase order before accepting
delivery accepted by referring to the goods the delivery (see example in
purchase order. The goods figure 11.20)
receiving officer should carefully Errors in Providing incentives for accuracy
check the goods to ensure counting Double-checking the count (only
they are not damaged, and that goods where cost effective to do so)
the quantity of goods being received
delivered is correct. The goods Using blind purchase orders
receiving officer signs the Using barcodes/RFIDs
delivery docket to indicate that
the delivery has been accepted.
Theft of Physical access controls
inventory Periodic inventory counts
Correct documentation for all
transfers of inventory
Segregation of duties
3.2 Record Goods The goods receiving officer Data entry Use of barcodes or RFIDs
goods receiving officer records the details of the errors Exception reporting
received goods received. Identifying variances between
goods ordered and goods received
Data input edit checks identifying
variances at input stage

L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases › Bills ›

New Bill

Purchase Order PO-0002 is outstanding for this supplier. Copy line items to this bill.

From Date Due Date Reference Total

Clifton Bikes 20 Jul 2015 19 Aug 2015 0.00

Currency AUD Australian Dollar Amount are Tax Inclusive

Item Description Qty Unit Price Account Tax Rate Amount AUD

Subtotal 0.00
Add a new line
GST 0.00

Total 0.00

Save Approve Cancel

FIGURE 11.20 Internal control — checking existence of purchase order

Source: © Xero Limited.

510 Part 3 Systems in action

 2.0
Order goods

(29)

Supplier

(33) 3.1
Accept the
delivery

Supplier
(34)
Goods
received

(37)
(36)

3.2
Record goods
(39) (35)
received

(38)

Purchase
Inventory order

(40)

4.0
Pay for goods

FIGURE 11.21 Expenditure cycle level 1 logical diagram — process 3.0 Receive goods

Chapter 11 Transaction cycle — the expenditure cycle 511

 Sends goods
Supplier and
documentation

Correct Inputs goods Receives goods

Goods receiving officer Accepts goods
goods? received details received details

Records goods
Computer
received

Receives goods
Accounts payable
received details

FIGURE 11.22 Expenditure cycle process map — process 3.0 Receive goods

Pay for goods — activities, risks and controls

Process 4.0, pay for goods, comprises the following activities.
Approve the payment
An invoice, which is a request for payment for goods or services supplied, is received from the sup-
plier. The invoice may be delivered with goods, or sent at a later date. Invoices can be either paper or
electronic. Accounts payable staff should check the invoice for accuracy and compare it to the pur-
chase order and goods received data to make sure that what was ordered was delivered, and that the
goods received match what has been invoiced. This three-way match can be conducted manually or be
computerised. In a manual three-way check, accounts payable staff would physically match and com-
pare the three pieces of paper. If the details match, the copies are usually stapled together and stamped
‘matched’, or ‘approved’, prior to any additional processing. For computerised matching, the details of
the supplier invoice are input, and then details of the related purchase order and the goods receipt are
extracted and used to check that the details of the invoice are correct. Figure 11.23 shows an example
of an invoice input screen. Payment processing will only continue if the details of the purchase order,
goods received and invoice all agree. This three-way check helps reduce the risk of paying for goods not
received, or goods that were not ordered. Another common control in this area is to formulate and mon-
itor detailed expenditure budgets.

512 Part 3 Systems in action

 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases › Bills ›

New Bill

From Date Due Date Reference Total

Clifton Bikes 20 Jul 2015 19 Aug 2015 PO-0002 0.00

Currency AUD Australian Dollar Amount are Tax Inclusive

Item Description Qty Unit Price Account Tax Rate Amount AUD

Mountain: Mongoose 2015 Mountain Bike 16.00 600.00 630 - Inventory GST on Expenses 9,600.00
Mongoose 2015
Mountain Bike

Subtotal 9,600.00
Add a new line
Includes GST 10.00% 872.73

Total 9,600.00

Save Approve Cancel

FIGURE 11.23 Invoice input screen

Source: © Xero Limited.

Larger organisations may wish to consider the use of invoice-less trading or evaluated receipt settle-
ment techniques. These techniques ignore the supplier invoice when establishing a payment, relying
instead only on the data contained in the purchase order and the goods received report. If invoice-less
trading is being used, it is vital that purchase order pricing is accurate, as any resulting payment will
be based solely on the price data held in the original purchase order. Under invoice-less trading, when
goods received data is entered and matched against a purchase order a supplier payment is generated
automatically. This reduces the risk of paying for goods not received, as it is not possible to pay a
supplier unless the goods receipt has been recorded. This technique increases payables efficiency as it
reduces the labour costs incurred to process and match invoices to the purchase order and goods received
documentation. Risks related to errors in supplier invoices are eliminated by the use of invoice-less
trading, but, alternatively, an organisation may wish to check the mathematical accuracy or double-check
all matched supplier invoices prior to payment.
A significant risk in the area of accounts payable is the potential to pay invoices twice. Common
techniques to control for this risk include allowing payments to be made using original source docu-
ments only, or physically stamping or otherwise marking paid invoices to avoid double processing. Most
computerised accounts payable software restricts the processing of duplicate transaction numbers for a
given supplier. In order for this computerised control to work effectively, it is important to ensure that
duplicate supplier accounts are not created for a single supplier. It is also important to control the ability
to change or add supplier data; that is, staff responsible for processing payments should not be allowed
to add new suppliers or change existing suppliers.

Chapter 11 Transaction cycle — the expenditure cycle 513

 Once accounts payable staff have determined that an invoice should be paid, the payment due
date is recorded. Figure 11.24 shows an example input screen for establishing a payment. This
includes establishing the due date for payment of the invoice, which should be based on payment
terms originally negotiated with the supplier. Existing supplier details (name, address and payment
terms) are extracted for use in establishing the payment. Payments being made electronically will
also require additional supplier data relating to the supplier’s bank account or electronic payment
details.

L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases ›

Bills

New Bill New Credit Note Import Export

All Draft (1) Awaiting Approval (1) Awaiting Payment (4) Paid Repeating

Schedule of Planned Payments

All 20 Jul 2015

35,500.00

Enter Reference, Contact or Amount Search Within Start Date End Date
Due date 19 Jul 2015 Search or Clear

Print Batch Payment Schedule Payments 1 item selected | 35,500.00 AUD 2 items | 57,100.00 AUD Search

Ref From Date Due Date Planned Date Paid Due

Hocking Sports Supplies 10 Jun 2015 25 Jun 2015 20 Jul 2015 0.00 35,500.00

Reed Bike Importers 8 Jun 2015 15 Jul 2015 0.00 21,600.00

FIGURE 11.24 Vendor payment screen

Source: © Xero Limited.

A common risk relating to payment is that of generating an incorrect payable. This risk is par-
ticularly relevant where large volumes of data are keyed into computerised systems from suppliers’
invoices. Controls to reduce this risk include processing invoice inputs in batches and verifying
the associated batch totals, and using preformatted data entry screens and data entry input masks
where possible. Exception reports identifying unusual or large payments are also helpful for reducing
this risk.
Accounts payable staff need to decide whether to take advantage of any payment discounts offered
when establishing the due date for payment. This decision may be made based on a corporate policy, or
it could be left up to the discretion of the individual. A discount should only be taken where cash flow is
sufficient to support the early payment, and the discount offered is a reasonable inducement. The risk of
failing to take available purchase discounts can be reduced by automatically calculating payables dates
based on supplier terms and a computerised calendar function.
Details of the approved payment (due date, amount, supplier and invoice details) are written into
the accounts payable data store and subsequently transferred to the financial cycle where they are used

514 Part 3 Systems in action

to update general ledger asset and liability accounts. Note that if an organisation is using commit-
ment accounting (where liabilities are recognised when goods are ordered, rather than when goods are
received) the details of payments due for purchase orders raised would be transferred earlier in the pro-
cess, that is, immediately after the purchase order is created.
Not all payments processed have a related purchase order; common examples are recurrent payments
such as rent or loan payments. Many organisations also allow employees to pay for small expenses
directly and subsequently reimburse them. The controls over these payments need to be stronger and
better enforced than those of payments for which there is a purchase order. Payments with no purchase
order have sidestepped all the controls in place over the ordering and receiving of goods. Typically, a
payment request for which there is no purchase order would need to be independently checked and
authorised by a staff member with sufficient seniority and financial delegation before the payment can
be processed. Vouchers of the kind shown in figure 11.25 are commonly used to document these pay-
ments. Another common control technique used is to monitor the proportion of payments being pro-
cessed without a related purchase order. If this proportion is increasing, it may indicate a weakness or
inefficiency in the purchase order process that should be addressed.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Disbursement voucher No: 1458

Remit to: Tech Supplies (Vendor Ref: 2839)

782 Mount Macedon Terrace
Victoria 3547

Order processed: Prepared by:

26/07/15 Dianne Gillian

Vendor invoice Date Amount Returns and Discount Net amount

number allowances

67289 30/07/15 3792.50 NIL 379.25 3413.25

FIGURE 11.25 Sample disbursement voucher

Make the payment

On the due date, the payment is processed. An example is shown in figure 11.26. A payment may
relate to a single invoice or to a number of invoices if multiple invoices have been received and
approved since the last payment made to the supplier. Payment can be made in a number of ways. A
payment may be generated by printing cheques based on data in a batch file created automatically by
the computer, or by creating a hand-written cheque if the volume of payments is small. If payment is
being made electronically, the computer may automatically generate a file to be sent to the bank for
processing, or accounts payable staff may log on to an online banking website and process the pay-
ments individually. Online banking is an internet-based banking facility that allows organisations to
manage and view their bank accounts online and conduct transactions such as transfers from those
accounts.

Chapter 11 Transaction cycle — the expenditure cycle 515

 Dashboard Accounts Payroll Reports Contacts Settings

Purchases › Bills ›

View Bill

Awaiting Payment ? Print PDF Bill Options

From Date Due Date Total

Hocking Sports Supplies 10 Jun 2015 25 Jun 2015 35,500.00
89 Spencer St
WEST MELBOURNE VIC 3003
AUSTRALIA
Edit address

Amounts are Tax Exclusive

Item Code Description Quantity Unit Price Account Tax Rate Amount AUD

BMX Mongoose BMX Bike 25.00 196.36 Inventory GST on Expenses 4,909.09

Road Samson Road Bike 70.00 390.91 Inventory GST on Expenses 27,363.64

Subtotal 32,272.73

Total GST 10% 3,227.27

TOTAL 35,500.00

Make a payment ?
Amount Paid Date Paid Paid From Reference

35500.00 20 Jul 2015 Australia Bank Chq 9001

Add Payment

FIGURE 11.26 Vendor payment processing screen

Source: © Xero Limited.

Whichever form of payment is adopted, the payment needs to be sent to the supplier. This may be in
the form of a cheque that is posted to the supplier, or an electronic payment that is transferred though
an online banking system. Both forms of payment should include a remittance advice that explains
the accompanying payment. A remittance advice would usually list which invoices are being paid,
the individual amounts of those invoices and the total payment remitted. Generating and transmitting
payments carries a risk of misappropriation of the cash, cheques or electronic funds transfers (EFTs).
Common controls when cheques are issued include restricting access to blank cheque stationery and
requiring dual signatories. For larger volume cheque printing, many firms also use a cheque signing
machine to control and log all cheques released. Controls over EFTs include the use of secure logins
and passwords, requiring two people to authorise payment transfers, and severely restricting access
to online banking functionality. Segregation of duties and performing regular bank reconciliations are
vital to control payment-related risks. People responsible for making payments ideally would not also
be responsible for establishing payments, or for arranging to purchase goods. Bank reconciliations
should be performed by an employee who has no other revenue or expenditure responsibilities if at
all possible.
Once the payment has been successfully processed, summarised details of the payment made should
be written to the relevant supplier record in the accounts payable data store, and the full details of the
payment should be recorded in a separate cash payments data store. The data contained in the accounts
payable data store is transferred to the financial cycle, where it is used to update general ledger accounts,
as discussed in chapter 12.

516 Part 3 Systems in action

Pay for goods — DFD
The level 1 DFD in figure 11.27 contains a lower level of detail about the final process represented in
the level 0 logical DFD in figure 11.5. This process takes place after the goods have been received in the
preceding process.

2.0 3.0
Order goods Receive goods

(30)
(40)
Purchase
order

Goods
received
(42)

4.1
Approve the (43)
(41)
payment
Supplier

(45)
(44)
Supplier (47)

Accounts
payable

(46)
(49) 4.2
Make the (48)
payment
(50)

(51)

(52)

Cash
payments
Financial
cycle

FIGURE 11.27 Expenditure cycle level 1 logical diagram — process 4.0 Pay for goods

Chapter 11 Transaction cycle — the expenditure cycle 517

 Sends invoice for Receives
Supplier
goods supplied payment

Requests Receives
Accounts payable Is invoice Inputs payment Receives
purchase order payment due
officer correct? details payment details
details details

Supplies Records
Computer purchase order payment due Is payment Makes payment
details details due?

Receives
Receives
Finance office payment due
payment details
details

FIGURE 11.28 Expenditure cycle process map — process 4.0 Pay for goods

Summary description of activities in paying for goods

Table 11.6 summarises the activities when receiving and recording payment for goods, as depicted
in figures 11.27 and 11.28. Table 11.2 explains the logical data flows depicted in the logical DFD in
figure 11.27 and process map in figure 11.28. Exploring the diagrams in conjunction with the material
contained in the tables will assist in improving your understanding of the process depicted.

TABLE 11.6 Activities in paying for goods

Usually Typical
Activity # Activity conducted by Activity description risks encountered Common controls

4.1 Approve Accounts The accounts Failing to notice Mathematical accuracy check
the payable officer payable officer errors in supplier Verification — double-checking invoices
payment checks the invoice invoices Independent validation of supplier
for accuracy and invoices, invoice-less trading (i.e.
compares it to the payment based on purchase order
purchase order and details on receipt of goods, rather than
goods received data payment based on invoice details)
to make sure that
what was ordered Paying for goods Restricting processing of duplicate
was delivered, not received transaction numbers (see example in
and that the data figure 11.29)
matches what has Budgets
been invoiced. Invoice-less trading
Once the accounts
Failing to take Automated calculation of payables
payable officer has
available purchase dates
determined that the
discounts
invoice should be
paid, the payment is
created.

518 Part 3 Systems in action

 Usually Typical
Activity # Activity conducted by Activity description risks encountered Common controls
4.1 Approve Accounts Paying an invoice Paying on original source documents
the payable officer twice only
payment Stamping or otherwise marking paid
invoices
Restricting processing of duplicate
transaction numbers (see figure 11.29)
Controlling access to the supplier master
file, and not allowing duplicate suppliers
4.2 Make Accounts On the due date, Recording or Use of preformatted screens and data
the payable officer the payment should posting errors in entry input masks where possible
payment be automatically accounts payable Exception reports identifying unusual or
processed. records large payments
Preparing and sending remittance advices
Misappropriation Restricting access to cheque blanks
of cash, cheques, Using dual signatories/logins
EFTs Using a cheque signing machine
Segregation of duties
Performing regular bank reconciliations
Exception reporting

L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Purchases › Bills ›

New Bill

From Date Due Date Reference Total

Reed Bike Importers 20 Jul 2015 15 Aug 2015 2015-2 0.00

A bill from Reed Bike Importers with reference 2015-2 already exists. Open

Currency AUD Australian Dollar Amount are Tax Inclusive

Item Description Qty Unit Price Account Tax Rate Amount AUD

Subtotal 0.00
Add a new line
GST 0.00

Total 0.00

Save Approve Cancel

FIGURE 11.29 Internal control — screen showing restriction on processing duplicate transactions
Source: © Xero Limited.

Chapter 11 Transaction cycle — the expenditure cycle 519

Physical DFD — determine demand for goods
The physical DFD depicted in figure 11.30 shows an example of how demand for goods may be pro-
cessed. The physical diagram draws the process from a different perspective to the logical DFD of this
process contained in figure 11.7, as it shows who is involved in the activities of the process, rather than
when those activities occur. This process of determining demand for goods involves the purchase requi-
sition officer, who interacts with a central computer and one or more internal departments who request
goods. Outputs from this process are sent through to the department that originally requested the goods,
and also to the purchase order officer for use in subsequent parts of the expenditure cycle.

Production

Misc.
departments (1)
(17) (18)
Purchase
(2) requests

(4)
1.0
(16) Purchase
requisition (5)
officer

(3) Inventory
Inventory
department (7)

(8)
(10)

(11) (14)

(15) 2.0
Computer

(19)
(9)

(13) (12)

Sales
Purchase
requisition

Purchase
order officer

FIGURE 11.30 Physical DFD — determine demand for goods

520 Part 3 Systems in action

 Details of the physical data flows in figure 11.30 are contained in table 11.7. As this diagram is drawn
from a different perspective to the logical DFD it contains far more detail about the interactions between
each of the entities involved in processing the sales order.

System flowchart — determine demand for goods

The DFD in figure 11.30 shows an example of how demand for goods may be physically determined.
The logical DFD in figure 11.7 and process map in figure 11.8 show that same process from a logical
perspective. The flowchart contained in figure 11.31 shows that same process from yet another perspec-
tive. The system flowchart in figure 11.31 is the most detailed picture of the process, and includes both
logical and physical perspectives. The detail contained in the system flowchart is useful when consid-
ering process redesign and when analysing the control environment of the process depicted. Details of
the flows shown in the flowchart in figure 11.31 are documented in table 11.7.

TABLE 11.7 Description of data flows in physical DFD and flowchart — determine demand for goods

Flow # Data source Data destination Explanation of the physical data flows

1 Production Purchase requisition Requests to purchase raw materials required for production of goods.
department officer These requests may be automatically generated by production cycle
control software, or created manually by production staff.

2 Miscellaneous Purchase requisition Requests to purchase consumable items used in the day-to-day running
departments officer of the business, for example, stationery items. This type of request is often
ad hoc and created manually by various departments.

3 Inventory Purchase requisition Requests to purchase items required for inventory; these are items that
department officer the business purchases with the intention of holding them temporarily
and making them available for sale to customers. These requests may
be triggered automatically by reaching a reorder point predefined in
the inventory software, or they may be created manually by inventory
management staff.

4 Purchase Purchase requests When requests are received by the purchase requisition officer, they
requisition officer may elect to hold them for processing until an economically viable order
quantity is reached. If this happens, the requests will be filed temporarily
until sufficient requests are received.

5 Purchase Purchase requisition Requests to purchase items are retrieved from the file for processing once
requests officer sufficient quantities have been requested.

6 Purchase Purchase requisition After a request is received, a purchase requisition can be processed (not
requisition officer officer depicted in a physical DFD).

7 Purchase Computer The purchase requisition officer requests previous sales and
requisition officer inventory data.

8 Inventory data Computer The computer extracts the current inventory data for the requested
store product.

9 Sales data store Computer The computer extracts the previous sales data for the requested
product.

(continued)

Chapter 11 Transaction cycle — the expenditure cycle 521

TABLE 11.7 (continued)

Flow # Data source Data destination Explanation of the physical data flows

10 Computer Purchase requisition The computer displays the sales and inventory data to the purchase
officer requisition officer. The officer uses this data, along with the data on
the purchase request, to determine what quantity of goods should be
ordered.

11 Purchase Computer The purchase requisition officer requests the computer to create a
requisition officer purchase requisition.

12 Purchase Computer The computer extracts the number of the previous purchase requisition
requisition data processed. This number is incremented (usually by one) to assign a
store number to the new purchase requisition.

13 Computer Purchase requisition The computer stores the details of the new purchase requisition in the
data store purchase requisition data store.

14 Computer Inventory data store The computer updates the inventory record to include details of the goods
in the purchase requisition.

15 Computer Purchase requisition The computer prints out the new purchase requisition. This document may
officer also be electronic rather than paper based.

16 Purchase Inventory The purchase requisition officer advises the department that the
requisition officer department goods they requested have been requisitioned. This may also happen
electronically, in which case a message would be generated directly from
the computer.

17 Purchase Miscellaneous The purchase requisition officer advises the department that the
requisition officer departments goods they requested have been requisitioned. This may also happen
electronically, in which case a message would be generated directly from
the computer.

18 Purchase Production The purchase requisition officer advises the department that the
requisition officer department goods they requested have been requisitioned. This may also happen
electronically, in which case a message would be generated directly from
the computer.

19 Purchase Purchase order The purchase requisition is sent to the purchase order officer so a
requisition officer officer purchase order can be raised for the goods requisitioned. This may also
happen electronically, in which case a message would be generated
directly from the computer.

522 Part 3 Systems in action

 Purchase requisition officer Computer

Inventory
Production Misc. departments
department

(1) (2) (3)

Purchase
(4) request
Purchase
requests Sales
(5)
Purchase
request
(9)
(6)

Extract sales and

Request prior data (7)
inventory data

(8)
Sales and
(10)
inventory data

Inventory
(14)
Calculate
amount to
requisition

Requisition details
Create purchase
(11)
requisition

(12)
Production Purchase
requisition (15)

(1 (13)
8)

Misc. departments
(17) Advise Purchase
departments requisitions

Inventory )
(16
department
Purchase
requisition

(19)

Purchase order
clerk

FIGURE 11.31 Systems flowchart — determine demand for goods

Chapter 11 Transaction cycle — the expenditure cycle 523

11.6 Measuring expenditure cycle performance
LEARNING OBJECTIVE 11.6 Justify metrics to monitor expenditure cycle performance.
Process performance should be measured relative to how well the process outcomes achieve the overall
objectives of that cycle. At the start of this chapter the objectives of the expenditure cycle were described
as being to correctly establish demand for requested goods and services and produce purchase orders
that are accurate and appropriately authorised. Goods must be received in a timely fashion and both the
quality and quantity of goods delivered must be checked before acceptance. Payments made to suppliers
must be both timely and accurate.
To monitor performance against these objectives a range of metrics needs to be employed, along with
some realistic targets. Examples of suitable metrics or key performance indicators (KPIs) for the expen-
diture cycle objectives are shown in table 11.8.

TABLE 11.8 Example KPIs mapped to cycle objectives

Objective Example KPI

To correctly establish demand for requested goods • Number of invalid requests received
and services • Number of requester complaints

To produce purchase orders that are accurate and • Number of purchases from approved suppliers
appropriately authorised • Number of supplier complaints
• Number of accounts payable adjustments

To ensure goods are received in a timely fashion and • Number of quality complaints
both the quality and quantity of goods delivered are • Number of requester complaints
checked before acceptance • Number of returns to suppliers

To ensure payments made to suppliers are both timely • $ cash losses

and accurate • $ or # unauthorised payments
• Financial delegations compliance
• Discounts claimed/overlooked
• Average payment time
• Number of supplier complaints
• $ overpayments

summary
11.1 Reflect on the key objectives and strategic implications of the expenditure cycle.
The expenditure cycle consists of two phases. The first is purchasing, where the organisation interacts
extensively with external suppliers of goods and services. The objective of purchasing is to procure the
right goods for the right amount, and to receive those goods at the right time. In order to achieve this out-
come, purchases need to be properly approved and authorised; goods and services need to be obtained
from authorised suppliers; all purchase commitments and obligations need to be recorded accurately;
and accepted goods and services must meet quality and delivery specifications. Following the purchasing
phase is the accounts payable phase, where the objective is to pay the right people the right amount at
the right time. The accounts payable phase ensures that payments are both accurate and timely, while
ensuring that they maximise favourable settlement terms. In order to ensure the integrity of financial
reporting, all accounts payable liabilities must be recorded accurately and promptly.
The expenditure cycle is strategically important to an organisation, particularly in terms of the degree
of alignment with overall business strategy. The expenditure cycle can provide a competitive advantage

524 Part 3 Systems in action

by providing high-quality products and services, or by acting to contain costs. In terms of the purchasing
phase, failure to correctly manage purchasing can lead to systemic problems: an unreliable supply of goods
and services has the potential to negatively impact revenue, production and inventory management pro-
cesses. Buying too much, too little or the wrong items creates inventory problems and can lead to increased
costs or a decline in revenues. Arranging and making payments creates an exposure to potentially costly
errors and mistakes, whereas poor payment practices can damage cash flow and/or supplier relationships.
11.2 Evaluate common technologies underpinning the expenditure cycle.
There are a number of technologies suitable to support activities within the expenditure cycle. A range of
inventory management tools are available to help improve the ability to balance out supply and demand
for goods and services. Transparency and management of cash payments and cash flows can also be
improved by use of appropriate technologies. Enterprise resource planning (ERP) systems act to provide
tighter connections between demand and supply functions within the organisation, which are essential
for correct purchasing practices. Use of technologies such as electronic data interchange (EDI) can pro-
vide accurate, timely, cost-effective data sharing, and barcodes or radio frequency identification (RFID)
tags cut handling costs and improve data quality. Specialised supply chain management software (SCM)
can be used to improve both planning and execution of the supply chain. The ability to make electronic
payments provides a fast and comparatively inexpensive way for organisations to settle their accounts
with suppliers.
11.3 Recognise expenditure cycle data and key expenditure business decisions.
The expenditure cycle uses or produces data, including inventory, supplier, product, purchase order,
goods received and accounts payable data. Business process decisions are made at both strategic and
operational levels. Strategy-level decisions include whether the organisation should consolidate pur-
chases across units to obtain optimal prices, how IT can be used to improve both the efficiency and accu-
racy of the inbound logistics function, and identifying where inventories and supplies should be held.
Typical operational decisions include determining the optimal level of inventory and supplies to carry,
deciding which suppliers to purchase from, identifying if sufficient cash is available to take advantage of
supplier discounts and determining how payment can be made in order to maximise cash flow.
11.4 Summarise and prepare documentation synthesising the primary activities in the
expenditure cycle and the data produced by these activities.
Contextually, the expenditure cycle involves direct interaction with supplier entities outside the organ-
isation. Within the organisation, the expenditure cycle interacts with the production cycle, inventory
department and a range of miscellaneous departments, along with the financial cycle. Primary activities
in the expenditure cycle include determining the demand for goods, ordering goods from suppliers,
receiving goods and paying for goods received.
A range of data types are accessed and updated by activities within the expenditure cycle, including
inventory data and supplier data. Expenditure activities create purchase requests, purchase requisitions,
purchase orders, and accounts payable and cash payments data. Expenditure data are used to support
decision making related to the expenditure cycle, and also for evaluating process performance and
reporting financial results for the organisation.
11.5 Assess risks and compose control plans pertinent to the primary activities in the
expenditure cycle.
Activities within the expenditure cycle create exposure to a range of known risks. Risks related to deter-
mining demand for goods include under- or overestimating requirements and requesting unnecessary
items. Risks related to ordering goods include using unauthorised suppliers, paying too much for goods,
buying poor-quality goods and kickbacks or collusion between suppliers and purchasing staff. Risks
related to receiving goods include receiving unordered goods, errors in counting goods, theft of inven-
tory and data entry errors. Risks related to paying for goods include failing to notice errors in supplier
invoices, paying for goods not received, failing to take available discounts, paying an invoice twice,
incorrectly recording accounts and misappropriation of cash or electronic funds transfers.

Chapter 11 Transaction cycle — the expenditure cycle 525

 To reduce risk exposure, the control environment must include controls that minimise human error, as
well as prevent fraudulent behaviour. In the case of the expenditure cycle, controls over inventory and cash or
EFTs are of primary importance. Significant controls in the expenditure cycle include obtaining approvals for
purchase requisitions and purchase orders, regular monitoring of supplier performance, appropriate segre­
gation of duties, physical security over goods, exception reporting and regular bank reconciliations.
11.6 Justify metrics to monitor expenditure cycle performance.
Process performance should be measured relative to the desired outcomes of the process. To monitor
cycle performance, a wide range of metrics needs to be employed, along with some realistic targets.
Examples of suitable performance metrics for an expenditure cycle include numbers of data entry errors,
product quality levels, cycle times to procure goods, volume of returned goods, number of discounts
claimed and average payment times achieved.

Key terms
Automatic reorder point An inventory order point based on predefined minimum inventory
levels recorded for individual items. When the stock on hand drops down to this level a purchase
requisition is automatically generated.
Blind purchase order A copy of the purchase order with quantities concealed, so as to force a count
of goods received.
Cash budget A budget showing forecast levels of future cash flows into and out of the organisation.
Electronic data interchange (EDI) A bespoke link that enables exchange of data between two
separate computer systems. It is used when transaction flow and volume are large and transaction
syntax is predictable.
Enterprise resource planning (ERP) system An integrated suite of software that records and
manages many different types of business transactions within a single integrated database. Examples
include SAP and Oracle.
Exception report A report type that is designed specifically to identify exceptions for particular
transactions. An example is a report identifying any sales orders which have been shipped but not
billed, or a report identifying all customers who have overdue accounts receivable accounts.
Just-in-time (JIT) supply chain An inventory management strategy where the goal is to time the
ordering of goods so they arrive just in time to be used, so as to reduce inventory holding costs.
Metric A specific measure used for a particular purpose. An example of a metric is the number of bad
debts the organisation has, which could be used to monitor accounts receivable or sales performance.
Online banking An internet-based banking facility that allows organisations to manage and view their
bank accounts online and conduct transactions such as transfers from those accounts.
Reconciliation An activity where two different sets of data that purport to represent one transaction or
set of events are compared to see if they agree. A common example is a bank reconciliation, which
reconciles the organisation’s accounting records of cash inflows and outflows with the bank’s record
(i.e. a bank statement).
RFID A small plastic tag attached to an item which contains data about that item and is able to be
scanned using an RFID reader.
Settlement terms Payment terms negotiated with a supplier.
Status code A code on transactions that are moving through an iteration of a process indicating which
stage of the process the transaction is at. As an example, a sales transaction may be first ‘created’,
then ‘picked’, then ‘packed’, then ‘shipped’, then ‘paid’. When each of these activities has been
completed, the status of the transaction is changed to reflect the new status.
Supply chain An integration of suppliers and customers with the aim of producing and distributing
goods and services by quantity, location and time to minimise costs and satisfy required service
levels. Specialised software in this area is known as supply chain management software (SCM).

526 Part 3 Systems in action

DISCUSSION QUESTIONS
11.1 Martin Ltd has always had a strategy of product differentiation; that is, providing high-quality
products and extracting a price premium from the market. During the recent economic downturn,
Martin Ltd saw its customer base diminish, and decided to move strategically to a cost leadership
strategy, that is, to try to sell more products at a lower price.
(a) What are the implications of this strategy change for the expenditure cycle?(LO1)
(b) What changes would you expect to see in the expenditure cycle?(LO4)
(c) What are the implications of this strategy change in terms of the usefulness of historic sales
data for decision making related to demand predictions?(LO3)
11.2 Johnson Ltd has decided to use online banking electronic payment facilities to pay
suppliers for goods.
(a) What controls would you expect to see introduced to ensure the safety of the online banking
data?(LO5)
(b) Which activities in the accounts payable process would be affected? (LO2, LO4)
(c) What changes would you expect to see in these activities?(LO4)
(d) What metrics could you use to measure the success of this initiative post implementation?
 (LO6)
11.3 Nguyen Ltd has just realised that it has a problem with its expenditure data, as its goods received
records do not easily identify whether a supplier has delivered the ordered goods on the due date.
(a) What decisions made during the expenditure cycle would be affected by this data problem?
 (LO3, LO4)
(b) How would those decisions be affected? How would this data problem affect the performance
of the expenditure cycle? (LO3, LO4, LO6)
(c) How would this data problem affect other processes at Nguyen Ltd? (LO1, LO3, LO4, LO6)
11.4 Wilson Ltd has a reconciliation problem. The amount of new goods booked into inventory
records by the warehouse staff does not always seem to match with the amount of goods
recorded as received by the goods receiving staff. Wilson Ltd seems to have good controls: it has
separated the receiving and warehousing of goods, and it regularly conducts ad hoc duplicate
counts of inventory items received.
(a) Which internal controls might be missing?(LO5)
(b) What could you do in order to investigate this problem?(LO4)
11.5 Anderson Ltd has a new CEO who is keen on improving process cycle times. She has reviewed the
process documentation for the expenditure cycle and is asking you to stop accumulating purchase
requests before determining the demand for goods as it appears to be slowing down the process.
(a) Should you agree to stop accumulating the purchase requests? Why or
why not? (LO1, LO3, LO5)
(b) If you do not agree to stop accumulating purchase requests, how would you explain this
decision to the CEO? (LO1, LO5)
(c) If you do agree to stop accumulating purchase requests, how would you justify this change to
the purchasing manager? (LO1, LO5)
(d) If you stop accumulating purchase requests, would you need to measure the cycle
performance differently? (LO1, LO6)

SELF-TEST ACTIVITIES
11.1 Which of the following helps to determine demand for products?(LO3)
(a) The level of previous sales.
(b) The forecast for future sales.

Chapter 11 Transaction cycle — the expenditure cycle 527

 (c) The business strategy.
(d) All of the above.
11.2 When choosing a supplier you should consider the:(LO3)
(a) product price only.
(b) product quality only.
(c) supplier service levels only.
(d) business strategy.
11.3 An organisation has committed to purchase goods from a supplier when:(LO3)
(a) purchasing staff obtain a quote for the goods.
(b) a purchase request is created.
(c) a purchase order is created.
(d) a purchase requisition is created.
11.4 Supply chain management software (SCM) is not useful for:(LO2)
(a) identifying product demand.
(b) making payments to suppliers.
(c) receiving goods.
(d) routing goods.
11.5 The expenditure cycle could receive purchasing requests from:(LO4)
(a) the production cycle.
(b) the inventory department.
(c) miscellaneous departments.
(d) all of the above.
11.6 If an organisation does not use authorised or approved suppliers, there is a risk that:(LO5)
(a) it may pay too much for the goods it buys.
(b) it may buy poor quality goods.
(c) frauds such as kickbacks may occur.
(d) all of the above.
11.7 Goods should be counted and checked on receipt when:(LO5)
(a) the number of goods is small enough to count them easily.
(b) the cartons look damaged.
(c) the delivery docket has a barcode on it.
(d) all goods deliveries should be checked and counted.
11.8 You should take a supplier discount for early payment when:(LO3)
(a) the goods have been delivered.
(b) the invoice has been received.
(c) you have enough cash available to pay the invoice early.
(d) the supplier asks you to pay early.
11.9 Not checking that goods have been received within a reasonable period of time for
all purchase orders placed increases the risk of:(LO5)
(a) running out of stocks of the goods.
(a) not paying for the goods.
(c) incorrect inventory records.
(d) receiving the wrong goods.
11.10 Using a barcode scanner to record goods received reduces the risk of:(LO2)
(a) counting the goods incorrectly.
(b) forgetting to record the goods received.
(c) neither (a) nor (b).
(d) both (a) and (b).

528 Part 3 Systems in action

PROBLEMS
The case narrative below (AB Hi-Fi) will be used to complete problems 11.1–11.14. Make sure you read
and understand the activities and the case thoroughly before you commence work on the problems.

AB Hi-Fi expenditure cycle

AB Hi-Fi is a multi-store retail business that sells products such as DVDs, CDs, mp3 players, game consoles
and TVs. AB Hi-Fi has a central warehouse that is located in Melbourne. All products purchased by the busi-
ness are delivered to this central warehouse. The narrative of the AB Hi-Fi expenditure cycle follows.
Process 1.0 Determine demand for goods
Purchase officers at AB Hi-Fi monitor stock levels via the computer. The computer has predefined reorder
points and reorder quantities for each inventory item. When stock levels for a particular item drop down to
this reorder point a purchase requisition is automatically generated by the computer and forwarded via email
to the purchase officer responsible for these items. The purchase officer is responsible for reviewing sales
trends for this item and deciding whether to reorder the goods listed on the purchase requisition. The pur-
chase officer can cancel the order if they feel that the goods are not worth reordering, amend the purchase
requisition if they think that the quantity is too high or too low, or accept the requisition without change. Once
the purchase officer has made a decision about the purchase requisition, they log on to the computer and
open the purchase requisition. They make any changes required to the quantities and products on the pur-
chase requisition, and then mark the requisition as complete by ticking on a check box.
The completed purchase requisition is then sent via email to the purchasing manager for review. The
purchasing manager logs on to the computer and opens the purchase requisition. The purchasing man-
ager is offered a choice of two tick boxes for each open purchase requisition. If the manager selects the
‘reject’ box, the purchase requisition is cancelled and no further action is taken. If the purchasing man-
ager selects the ‘accept’ box, an email is sent to the purchase officer informing them that the purchase
requisition has been approved.
Process 2.0 Order goods
When the purchase officer receives the approved purchase requisition email, they log on to the com-
puter and request a list of approved suppliers for each of the items on the approved requisition. The
purchase officer sends an electronic copy of the purchase requisition via email to each of the approved
suppliers, requesting quotes for product and delivery costs and an estimated delivery date.
When all the quotes have been received, the purchase officer decides which supplier to place the
order with. The purchase officer logs on to the computer and opens the relevant purchase requisition.
They select the option to create a purchase order by ticking on a check box. The computer requests
input of a valid supplier number, then uses the supplier data and the purchase requisition data to pro-
duce a purchase order. The purchase order is sent via email to the supplier, the purchase officer and the
warehouse officer responsible for these products.
Process 3.0 Receive goods
As part of their trading agreement with AB Hi-Fi, all suppliers are required to provide a delivery docket
that lists the items they are delivering, the number of cartons being delivered and the purchase order
number the delivery relates to. On arrival at the warehouse the delivery driver hands the warehouse
officer two copies of the delivery docket. If there is no purchase order number included on the delivery
docket, the warehouse officer will refuse to take delivery of the items. The warehouse officer enters the
purchase order number from the delivery docket into the computer. The computer extracts the purchase
order status from the purchase order data store. If the purchase order number is invalid, or the status of
the purchase order is ‘closed’, the computer will display an error message, and the warehouse officer
will refuse to take delivery of the items. If the purchase order number is valid, the computer will display
a message indicating that it is OK to accept a delivery for this purchase order, and asking if the ware-
house officer would like to print a goods received report for the purchase order. The warehouse officer
requests the computer to print the goods received report. The computer retrieves a list of the items
ordered from the purchase order data store and the supplier details from the supplier data store. The
computer prints the goods received report on a printer in the office of the warehouse officer.

(continued)

Chapter 11 Transaction cycle — the expenditure cycle 529

(continued)

The warehouse officer counts the number of cartons and verifies the count against the delivery
docket. Once the warehouse officer has checked that the number of cartons delivered matches the
number of cartons on the delivery docket, the warehouse officer signs the first copy of the delivery
docket and gives the signed delivery docket to the delivery driver.
The warehouse officer opens the cartons and checks and counts the items delivered, and writes the
quantity of each item on the printed goods received report. Some orders are quite large, so individual
boxes are not always opened and counted; in this case, the warehouse officer relies on the external
label stuck to the outside of the carton. Once all the items are counted and checked, the warehouse
officer dates and signs the goods received report. The warehouse officer staples the completed goods
received report to the second copy of the delivery docket, then puts the completed goods received
reports in a tray on the desk of the goods receiving officer.
Each morning, the goods receiving officer retrieves the previous day’s completed goods received
reports from the tray on their desk. The goods receiving officer inputs the purchase order number
from the goods received report into the computer. The computer retrieves and displays the pur-
chase order data, without the item quantities. The goods receiving officer works through line by
line and inputs the quantities received for each item from the goods received report. Once the
goods receiving officer has accounted for all the items on the goods received report, they tick
a box on the computer screen to indicate that the goods received report input is complete. The
computer will update the purchase order and inventory data stores with the goods received infor-
mation and then display a message confirming the completion. The goods receiving officer dates
and signs the goods received report, and then sends the completed input goods received report
to the accounts payable officer. The goods receiving officer processes each completed goods
received report in the tray in the same way. The accounts payable officer receives the completed
input goods receiving report from the warehouse officer. The goods receiving report is filed in an
awaiting invoice folder.

Process 4.0 Pay for goods

As part of their trading agreement with AB Hi-Fi, all suppliers are required to provide the related pur-
chase order number on their invoice. When the accounts payable officer receives an invoice from a sup-
plier, they enter the purchase order number from the invoice into the computer. The computer extracts
the purchase order status from the purchase order data store. If the purchase order number is invalid,
or the status of the purchase order is ‘paid’, the computer will display an error message. If the pur-
chase order number is valid and unpaid, the computer will display a message indicating that it is OK
to make a payment against this purchase order, and asking if the accounts payable officer would like
to print the purchase order. The accounts payable officer requests the computer to print the purchase
order. The computer retrieves details of the items ordered from the purchase order data store and the
supplier details from the supplier data store. The computer prints the purchase order on a printer in the
office of the accounts payable officer.
The accounts payable officer retrieves the relevant goods receiving report from the awaiting invoice
folder. The accounts payable officer attaches the goods receiving report to the purchase order report
and the invoice, then checks to identify if there are any quantity discrepancies between the three
documents. If any quantity discrepancies are identified, the accounts payable officer sends the reports
to the warehouse supervisor. If no quantity discrepancies are identified, the accounts payable officer
inputs the purchase order number into the computer and requests a payment screen. The computer
displays a payment screen containing the purchase order details. The accounts payable officer enters
the invoice data (item quantity and price). The computer extracts the purchase order price from the
purchase order data store and compares the invoice price with the purchase order price. If there is a
price variation of more than 5 per cent, the computer displays a price variation message and routes
the payment data to the accounts payable supervisor for approval. If the invoice price is within 5 per
cent of the purchase order price, the computer displays a payment accepted message. The computer
calculates the payment due date based on details held in the supplier data store, records the invoice
in the accounts payable data store, and updates the purchase order and general ledger data stores.
The accounts payable officer files the goods receiving report, purchase order and invoice documents
in an awaiting payment folder.

530 Part 3 Systems in action

 At the end of each week the computer extracts details of payments due from the accounts payable data
store and produces a payments file which is forwarded electronically to AB Hi-Fi’s bank. The bank transfers
money from AB Hi-Fi’s bank account to the relevant suppliers in accordance with the details in the payments
file. After the payments file has been successfully transferred to the bank, the computer prints a report of
payments made on the central printer, then updates the accounts payable and general ledger data stores.
The accounts payable officer collects the printed report of payments made and retrieves the appropriate
documentation from the awaiting payment folder. The accounts payable officer matches documents in the
awaiting payment folder with the payments listed on the payments made report. Matched sets of documents
are attached to the payments made report, then filed in a paid folder.

11.1 Prepare a context diagram for the expenditure cycle at AB Hi-Fi.(LO4)

11.2 Prepare a level 0 logical DFD for the expenditure cycle at AB Hi-Fi.(LO4)
11.3 Prepare a process map for:(LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
11.4 Prepare a level 1 logical DFD for:(LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
11.5 Prepare a physical DFD for:(LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
11.6 Prepare a systems flowchart for:(LO4)
(a) process 1.0 at AB Hi-Fi
(b) process 2.0 at AB Hi-Fi
(c) process 3.0 at AB Hi-Fi
(d) process 4.0 at AB Hi-Fi.
11.7 Table 11.3 identifies two risks typically encountered when determining demand.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the determine demand process at
AB Hi-Fi.
(b) Determine how many of the common controls described in table 11.3 are present in the
determine demand process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
determine demand process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the determine
demand process at AB Hi-Fi in order to reduce the level of risk.
11.8 Table 11.4 identifies four risks typically encountered when ordering goods.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the order goods process at
AB Hi-Fi.
(b) Determine how many of the common controls described in table 11.4 are present in the order
goods process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
order goods process is, and how comprehensive the current internal controls are.

Chapter 11 Transaction cycle — the expenditure cycle 531

 (d) Prepare a recommendation describing any changes you would like to make to the order
goods process at AB Hi-Fi in order to reduce the level of risk.
11.9 Table 11.5 identifies four risks typically encountered when receiving goods.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the receive goods process at
AB Hi-Fi.
(b) Determine how many of the common controls described in table 11.5 are present in the
receive goods process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
receive goods process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the receive
goods process at AB Hi-Fi in order to reduce the level of risk.
11.10 Table 11.6 identifies six risks typically encountered when paying for goods.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the pay for goods process at
AB Hi-Fi.
(b) Determine how many of the common controls described in table 11.6 are present in the pay
for goods process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
pay for goods process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the pay for
goods process at AB Hi-Fi in order to reduce the level of risk.
11.11 (a) AB Hi-Fi has adopted a cost leadership strategy; the overall plan is to undercut competitors
on pricing and so gain market share. How well does the current expenditure process align
with this business strategy?
(b) Are there any opportunities to improve the degree of alignment between the expenditure
process and the business strategy? Explain what you would change and how this would
improve the strategic alignment.(LO1)
11.12 (a) Identify and describe the technologies that AB Hi-Fi uses in its expenditure process
activities.
(b) For each of those technologies you identified in part (a), how well does AB Hi-Fi use the
technology? Could you suggest a way to improve the business benefit obtained by use of
any of these technologies?
(c) Are there other suitable technologies available that AB Hi-Fi could be using for the
expenditure process activities? What additional technologies could AB Hi-Fi implement?
What business benefit would these additional technologies provide?(LO2)
11.13 During process 2.0 Order goods at AB Hi-Fi, a purchase officer has to decide which supplier
to purchase the requisitioned goods from. Take a moment to review this section of the narrative
before you complete the following questions.(LO3)
Required
(a)
What data does the purchase officer draw on when making the decision?
(b)
Where do the data you identified in part (a) come from?
(c)
Are these data reliable; that is, is there any possibility that there could be errors in the data?
(d)
Are these data sufficient to make the decision, or can you identify additional data that the
officer should consider when making the decision?
(e) What would be the consequences of an incorrect decision?
11.14 Explain how you would measure performance of the expenditure cycle at AB Hi-Fi,
specifically:(LO6)
(a) What metrics would you use to measure performance?
(b) For each metric, explain where you would obtain the data.

532 Part 3 Systems in action

 (c) For each metric, explain why it is a good metric to help measure how well the expenditure
cycle is meeting its objectives.

The case narratives below for Yayy Online will be used to complete problems 11.15–11.34. Make sure
you read and understand the activities and the case thoroughly before you commence work on the
problems.

Narrative of Yayy Online

Yayy is a specialised online store that sells only one product each day. In addition to selling only one
product each day, Yayy offers the product of the day for sale until their stock runs out, or until the end of
the day, whichever comes first. Typical Yayy products are inexpensive (generally between $15 and $50),
and are mostly technology-related gadgets.

Yayy Online — determining demand for goods

Yayy employs a product researcher who is responsible for identifying suitable products. The product
researcher opens a Microsoft Excel spreadsheet, which is stored on the local C: drive of the product
researcher’s PC using the filename ‘identified products week ending xx_xx_xx’, and inputs the details
(technical specifications, description and supplier) of any suitable product identified. The product
researcher also searches the sales database on the central computer for past sales of any similar
products. If a similar previous product can be located, the product code is added into a column in
the spreadsheet headed ‘totally looks like’ by the researcher, before the file is saved. Every Friday
morning, the product researcher opens the current week’s spreadsheet, prints out two copies of the
identified products report for the week, and then files one copy. The second copy is sent to the pur-
chase officer.

11.15 Prepare a context diagram for determining demand for goods at Yayy Online.(LO4)
11.16 Prepare a process map for determining demand for goods at Yayy Online.(LO4)
11.17 Prepare a level 0 logical DFD for determining demand for goods at Yayy Online.(LO4)
11.18 Prepare a physical DFD for determining demand for goods at Yayy Online.(LO4)
11.19 Prepare a systems flowchart for determining demand for goods at Yayy Online.(LO4)

Yayy Online — ordering goods

When the purchase officer receives the identified products report from the product researcher, they
contact each supplier via phone and ask them to fax details of the volumes of stock available, the
product price and the lead time for delivery for each of the products on the report. When a supplier
fax is received, the purchase officer inputs the information from the supplier fax and the identified
product report into a potential products screen on the central computer. After all relevant product details
have been entered, the purchase officer saves the potential product data, and then the supplier fax is
stamped ‘input’ and filed by the supplier name in an ‘awaiting approval’ file.
Every Wednesday night at 9 pm, the computer automatically checks to see if there are any new
potential products, and then sends a message to the product manager requesting they review and
approve the potential products. If there are no new potential products, then no message is sent to
the product manager. The product manager indicates whether products are approved for purchase by
entering either ‘y’ (for an approved product) or ‘n’ (for a product not approved) into a checkbox located
beside each product. The computer automatically updates the product status in the relevant datastore.
Every Friday afternoon, the purchase officer prints two copies of the approved product report on the
local printer, then retrieves the supplier faxes from the ‘awaiting approval’ file. The matched supplier
faxes are attached to the first copy of the approved product report and filed; the second copy of the
approved product report is sent to the sales manager. If any potential product is not approved, the sup-
plier fax relating to that product is disposed of in the rubbish bin.

Chapter 11 Transaction cycle — the expenditure cycle 533

11.20 Prepare a context diagram for ordering goods at Yayy Online.(LO4)
11.21 Prepare a process map for ordering goods at Yayy Online.(LO4)
11.22 Prepare a level 0 logical DFD for ordering goods at Yayy Online.(LO4)
11.23 Prepare a physical DFD for ordering goods at Yayy Online.(LO4)
11.24 Prepare a systems flowchart for ordering goods at Yayy Online.(LO4)

Yayy Online — receiving goods

The delivery driver delivers the goods, along with two copies of a delivery docket, to the warehouse
officer. The warehouse officer checks that none of the cartons looks damaged and that the number
of cartons is correct, and then signs both copies of the delivery docket. The first copy of the delivery
docket is returned to the delivery driver. The warehouse officer retrieves the matching purchase order
from their ‘awaiting goods’ file and opens each of the cartons to verify that the correct number of pro­
ducts have been delivered. Once the goods have been checked, they are placed in the packing room,
which is a small area close to the loading dock, designed to be readily accessible from both the ware-
house and the loading dock. The purchase order is attached to the second copy of the delivery docket
and filed in a ‘goods received’ file.

11.25 Prepare a context diagram for receiving goods at Yayy Online.(LO4)

11.26 Prepare a process map for receiving goods at Yayy Online.(LO4)
11.27 Prepare a level 0 logical DFD for receiving goods at Yayy Online.(LO4)
11.28 Prepare a physical DFD for receiving goods at Yayy Online.(LO4)
11.29 Prepare a systems flowchart for receiving goods at Yayy Online.(LO4)

Yayy Online — paying for goods

Suppliers post their invoices directly to the accounts payable officer. When an invoice is received, the
accounts payable officer looks up the supplier number on a printed list that is kept in their drawer, writes
that supplier number on the invoice and then enters the invoice data (including the supplier number) into
the computer. The computer sends a payment approval request to the product manager. The product
manager indicates whether invoices are approved for payment by entering either ‘y’ (for an approved
invoice) or ‘n’ (for an invoice not approved) into a checkbox beside the payment request. Once payment
has been authorised, the computer automatically records the invoice in accounts payable and updates
the general ledger.
Every Friday morning, the accounts payable officer reviews the open invoices (i.e. accounts pay-
able) and decides which ones should be paid. The accounts payable officer clicks on a check box
to select the invoices that are to be paid, and the computer prints a cheque, then updates the
accounts payable and general ledger. The accounts payable clerk signs the cheque and mails it to
the supplier.

11.30 Prepare a context diagram for paying for goods at Yayy Online.(LO4)
11.31 Prepare a process map for paying for goods at Yayy Online.(LO4)
11.32 Prepare a level 0 logical DFD for paying for goods at Yayy Online.(LO4)
11.33 Prepare a physical DFD for paying for goods at Yayy Online.(LO4)
11.34 Prepare a systems flowchart for paying for goods at Yayy Online.(LO4)

The case narratives below for Jays Outdoors will be used to complete problems 11.35–11.54. Make
sure you read and understand the activities and the case thoroughly before you commence work on the
problems.

534 Part 3 Systems in action

 Jays Outdoors’ expenditure cycle
Jays Outdoors is a retail business selling outdoor entertainment goods such as tents, sleeping bags,
camping furniture etc. Jays has a centralised Distribution Centre which delivers products to their stores
across Australia and handles online orders placed via Jays’ website. Jays’ suppliers are selected via a
tender process and contracted as the sole supplier of a product for a maximum of 12 months.
Process 1.0 Determine demand
As sales occur at stores and on the website, Jays’ central computer system uses the sales data to
update the inventory data store. At 4 am each morning, the computer at the Distribution Centre gen-
erates a ‘daily alert report’ listing all inventory items which are at or below their recommended reorder
point. The reorder point is based on the recent sales history of the product and the lead times of the
supplier, which are negotiated when the tender is awarded to a supplier. The daily alert report contains
the product code, the quantity of inventory on hand at the Distribution Centre available for shipping
allocation, the quantity on order awaiting delivery from the supplier, the supplier’s ID number, and the
reorder point. The computer sends the daily alert to the Merchandise Manager via an emailed link.
Each morning, the Merchandise Manager opens the email, clicks on the link provided and reviews
the report. Depending upon the lead time, the nature of the product and the Merchandise Manager’s
knowledge of sales promotions/specials, the Merchandise Manager decides to either order the item or
do nothing. The Merchandise Manager selects each item and inputs a quantity to be ordered beside the
item details, using a zero for any item they believe should not be reordered.

11.35 Prepare a context diagram for determining demand for goods at Jays Outdoors.(LO4)
11.36 Prepare a process map for determining demand for goods at Jays Outdoors.(LO4)
11.37 Prepare a level 0 logical DFD for determining demand for goods at Jays Outdoors.(LO4)
11.38 Prepare a physical DFD for determining demand for goods at Jays Outdoors.(LO4)
11.39 Prepare a systems flowchart for determining demand for goods at Jays Outdoors.(LO4)

Process 2.0 Order goods

Each night between 2 and 4 am, the computer automatically creates purchase orders for inventory
items that have an order quantity greater than zero. The purchase order includes the purchase order
number, product code, description, quantity, the supplier, the price, and the required delivery window
date based on the supplier’s contracted lead times. Purchase orders under $20 000 are automatically
recorded as status ‘2’ (approved) and routed to the supplier electronically. Purchase orders equal to
or greater than $20 000 are recorded as status ‘1’ (awaiting approval) and routed electronically to the
Merchandise Manager. The inventory data store is updated to reflect the products on order and awaiting
delivery from each purchase order.
During the day, the Merchandise Manager approves the purchase orders by selecting the ‘review pur-
chase orders’ menu item on the purchase order screen. The computer displays a screen that requires
the Merchandise Manager to enter their employee number and the status of the purchase order(s) they
want to review (i.e., ‘1’). The computer displays a summary screen listing the purchase order number,
the dollar value of the purchase order and the supplier’s code. The Merchandise Manager can drill down
into the purchase order details by clicking on the purchase order number on the summary screen, which
will trigger the computer to extract and display the full details of the selected purchase order. Before
approving the purchase orders, the Merchandise Manager must cancel any purchase orders they do not
want to approve by clicking in a tick box next to the purchase order number on the summary screen. After
clicking the tick boxes, the Merchandise Manager selects the ‘cancel selected purchase order’ button
on the screen, the system requests the Merchandise Manager to confirm that they want to cancel the
selected purchase order(s). On selection of ‘yes’, the computer changes the status of the purchase order
to ‘6’ (cancelled) and updates the inventory data store. The Merchandise Manager then clicks the ‘approve
purchase orders’ button at the bottom of the screen. The computer changes the status of all the remaining
purchase orders to ‘2’ (approved) and routes the confirmed purchase orders to the suppliers.

(continued)

Chapter 11 Transaction cycle — the expenditure cycle 535

(continued)

On receipt of a purchase order, the supplier’s agreement requires suppliers to ‘accept’ or ‘decline’ the
order by 6 pm that day. Suppliers ‘accept’ the purchase order electronically by sending an electronic
‘acceptance’; this ‘acceptance’ is taken as a guarantee of delivery. The contracts with suppliers include
penalties for failing to supply in full for an ‘accepted’ delivery order. On receipt of the electronic ‘accept-
ance’, the computer updates the status of the purchase order to ‘3’ (accepted). On receipt of a ‘decline’
by a supplier, the computer updates the status of the purchase order to ‘7’ (declined) and adjusts the
quantity awaiting shipment in inventory.

11.40 Prepare a context diagram for ordering goods at Jays Outdoors.(LO4)

11.41 Prepare a process map for ordering goods at Jays Outdoors.(LO4)
11.42 Prepare a level 0 logical DFD for ordering goods at Jays Outdoors.(LO4)
11.43 Prepare a physical DFD for ordering goods at Jays Outdoors.(LO4)
11.44 Prepare a systems flowchart for ordering goods at Jays Outdoors.(LO4)

Process 3.0 Receive goods

At 12 pm the day before the delivery is due, the Receiving Manager extracts all status ‘3’ purchase
orders due the next day and telephones the supplier to confirm the expected delivery. The Distribution
Centre has one loading bay area where up to 16 delivery trucks can be unloaded at the same time.
Suppliers’ delivery trucks are unloaded on a first come first served basis. When the truck enters the
yard, they drive through gates and stop at the Receiving Officer’s window and quote the purchase order
(or orders if multiple orders are being delivered) to the Receiving Officer. The Receiving Officer keys the
purchase order number into the computer and prints a ‘delivery docket’ based on the purchase order
details for each purchase order number quoted. Each delivery docket is given to the delivery driver
who is allocated a loading bay number. The delivery driver moves the truck to their allocated loading
bay and hands the ‘delivery docket’ to the Receiving Staff at the bay. The delivery driver unloads the
stock from the delivery truck onto a conveyor belt. As the stock is loaded onto the conveyor belt, the
Receiving Staff member scans the barcodes on the cartons/pallets using a handheld wireless scanner.
Suppliers are required to barcode all items to be delivered according to the Distribution Centre’s require-
ments stipulated in the agreement with the supplier. After all goods are unloaded and scanned, the
Receiving Staff member scanning the items selects ‘send’ and the information is sent to the computer,
which updates the inventory data store to reflect the delivery of inventory into the Distribution Centre. At
this stage, the purchase order status is updated to ‘4’ (delivered), and a delivery confirmation notice is
routed electronically to the supplier, confirming the quantity of goods received.

11.45 Prepare a context diagram for receiving goods at Jays Outdoors.(LO4)

11.46 Prepare a process map for receiving goods at Jays Outdoors.(LO4)
11.47 Prepare a level 0 logical DFD for receiving goods at Jays Outdoors.(LO4)
11.48 Prepare a physical DFD for receiving goods at Jays Outdoors.(LO4)
11.49 Prepare a systems flowchart for receiving goods at Jays Outdoors.(LO4)

Process 4.0 Pay for goods

After the goods received have been recorded, the computer compares the goods recorded as received
on the delivery confirmation with the goods ordered on the purchase order. If the goods received match,
then the purchase order status is updated to ‘5’ (payment being processed) and a future payment trans-
action is automatically created. The payment amount is based on the contracted price for the goods in
the purchase order, and the payment due date is derived from the terms of payment negotiated by the
supplier in their original contract. At 1 am every weekday, the computer identifies all purchase orders
due for payment that day and creates and sends a payment file to the bank for processing. The pur-
chase order status is updated to ‘8’ (received and paid).

536 Part 3 Systems in action

11.50 Prepare a context diagram for pay for goods at Jays Outdoors.(LO4)
11.51 Prepare a process map for pay for goods at Jays Outdoors.(LO4)
11.52 Prepare a level 0 logical DFD for pay for goods at Jays Outdoors.(LO4)
11.53 Prepare a physical DFD for pay for goods at Jays Outdoors.(LO4)
11.54 Prepare a systems flowchart for pay for goods at Jays Outdoors.(LO4)

FURTHER READING
Coyle, JJ, Langley, CJ, Gibson, B, Novack, RA & Bardi, EJ 2008, Supply chain management:
a logistics perspective, 8th edn, Cengage Learning Australia, South Melbourne.
Kaplan, RS & Norton, DP 2008, ‘Protect strategic expenditures’, Harvard Business Review, vol. 86,
no. 12, p. 28.
Porter, ME 1998, Competitive advantage: creating and sustaining superior performance, Free Press,
New York; Collier Macmillan, London.

SELF-TEST ANSWERS
11.1 b, 11.2 d, 11.3 c, 11.4 b, 11.5 d, 11.6 d, 11.7 d, 11.8 c, 11.9 a, 11.10 d

ENDNOTE
1. Retail Times 2008, ‘Getting behind the scenes — managing your supply chain’, Australian Retailers Association, 21 December,
www.retailtimes.com.au.

ACKNOWLEDGEMENTS
AIS Focus 11.1: © Australian Retailers Association / From ‘Getting behind the scenes — managing your
supply chain’ The ARA Retailer.
Figures 11.2, 11.10, 11.11, 11.14, 11.19, 11.20, 11.23, 11.24, 11.26, 11.29: Screen captures from Xero
used with permission. © Xero Limited and affiliates, 2015. Xero® and the Xero logo are registered
trademark of Xero Limited. Any data displayed in these images is fictitious, and any similarities with
any actual data, individual, or entity is purely coincidental.
AIS Focus 11.2: © ReadSoft.
Figure 11.17: © Markus Gann / Shutterstock.com.
Photo: © Stígur Karlsson / iStockphoto.

Chapter 11 Transaction cycle — the expenditure cycle 537

CHAPTER 12

Transaction cycle —
the general ledger and
financial reporting cycle
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

12.1 reflect on the key objectives and strategic implications of the general ledger and financial reporting
cycle
12.2 evaluate common technologies underpinning the general ledger and financial reporting cycle
12.3 recognise general ledger and financial reporting cycle data and key general ledger and financial
reporting business decisions
12.4 summarise and prepare documentation synthesising the primary activities in the general ledger and
financial reporting cycle and the data produced by these activities
12.5 assess risks and compose control plans pertinent to the primary activities in the general ledger and
financial reporting cycle
12.6 justify metrics to monitor general ledger and financial reporting cycle performance.
Introduction
General ledger and financial reporting activities are critical to ongoing business success. The general
ledger and financial reporting cycle commences when budgets are created and ends when reports have
been generated and distributed. During this cycle all data needs to be validated and correctly input and
transferred. Adjusting journal entries must be prepared accurately and independently authorised. Reports
must be well designed and contain relevant and accurate data.
This chapter commences with an overview of the general ledger and financial reporting cycle, and then
considers the strategic implications of that cycle. Technologies that underpin the cycle are discussed, and
then the data produced and consumed during the cycle activities are identified. Typical process business
decisions are examined, along with some of the primary considerations related to those decisions. A
general ledger and financial reporting cycle is fully documented using process map data flow diagrams
and flowcharts, along with a set of tables containing additional details to aid in understanding the process
activities, and the related risks and controls of the activities. Finally, issues relating to measuring perfor-
mance of the general ledger and financial reporting cycle are discussed, and examples of performance
metrics suitable for measuring general ledger and financial reporting cycle performance are provided.

12.1 General ledger and financial reporting cycle

overview and key objectives
LEARNING OBJECTIVE 12.1 Reflect on the key objectives and strategic implications of the general
ledger and financial reporting cycle.
The general ledger and financial reporting cycle summarises, adjusts and reports on data from all the previous
operational cycles. During the general ledger and financial reporting cycle, budgets are created and agreed
upon, and transactional-level data are accumulated, summarised, adjusted and, finally, reported to internal
and external users. Most decision making by managers within the organisation is based on data supplied by
the financial reporting cycle; investors rely on these reports when making investment decisions; and reports

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 539
are also supplied to external regulators for assessing compliance with relevant corporate legislation. Assuring
the timeliness, validity, accuracy and completeness of reported data is critical to organisational success. The
organisational units most involved in the general ledger and financial reporting cycle are shown in figure 12.1.
The first part of the financial reporting and general ledger cycle involves creating an operational
budget for the organisation. Budgets are usually created on an annual basis and updated monthly or
more frequently if required. The purpose of budgeting is to facilitate organisational planning and control.
Creating budgets requires careful estimation of future activity levels and the associated potential costs
and revenues; finalised budgets are then used as a control measure to help ascertain and monitor required
organisational and individual performance levels. In order to motivate desirable behaviour by managers
within the organisation, budgets should be framed so that activity targets are achievable but challenging.
When reporting and monitoring using variance analysis (budget estimates compared to actual results),
it is important to identify the root cause of any variances observed. As an example, an unfavourable vari-
ance between budgeted and actual data may be the result of poor performance, or it is possible that budget
estimates were set at an unrealistic or unachievable level. It is necessary to identify which of these circum-
stances apply, as differing remedial actions are appropriate. An incorrect budget estimate should be cor-
rected and analysis should be undertaken to determine how the estimation error occurred in order to prevent
recurrence. If the budget is realistic but poor performance is the underlying cause of the variance, the poor
performance should be addressed via performance management of the individual or division involved.

Chief executive
officer

Director Director Director Director Director

administration finance or logistics marketing sales
accounting

Funds Inventory Sales order

Personnel Advertising
disbursement control processing

Office Customer
operations Billing Purchasing service

Tax planning Receiving

Maintain accounts
Storage
payable

Budgeting Production

Update accounting
Shipping
records

FIGURE 12.1 Organisational units in the general ledger and financial reporting cycle
Note: The dashed lines with the arrows show the business activities that each unit is responsible for.

540 PART 3 Systems in action

 Once budgets have been finalised, the ongoing work of extracting transactional data generated during
the operational transaction cycles (revenue, expenditure, production and payroll) and transferring a sum-
marised version of these transaction streams into the relevant general ledger accounts takes place. This
initial set of activities creates a trial balance of the accounts. An example of a trial balance is shown in
figure 12.2. It is important to note that this extraction activity does not provide any assurance that the
original transactions were recorded accurately. If an operational process has a control weakness that
results in inaccurate data being recorded at a transactional level, this same flawed data will be transferred
into the general ledger accounts.
At periodic intervals, a bank reconciliation is performed in order to independently verify the bal-
ances of the cash-based general ledger accounts. After this reconciliation is successfully completed,
adjusting journal entries are prepared and input. These adjusting journals create an adjusted trial balance,
where the values contained in the accounts comply with the requirements for recognising revenues and
expenses contained in the accounting standards. Once the adjusted trial balance has been finalised, finan-
cial reporting can take place.

Trial Balance
L & E bicycles
As at 22 July 2015

Account Debit Credit YTD Debit YTD Credit

Revenue
Sales (200) 34,886.36 34,886.36

Expenses
Advertising (400) 436.36 436.36
Bank fees (404) 20.00 20.00
Cost of Goods Sold (310) 26,681.75 26,681.75
Insurance (433) 13.64 13.64
Light, Power, Heading (445) 159.09 159.09
Printing & Stationery (461) 18.18 18.18
Assets
Accounts Receivable (610) 1,790.00 17,080.00
Australia Bank 2,175.00 21,275.00
Inventory (630) 4,012.92 21,405.45
Liabilities
Accounts Payable (800) 12,344.28 46,555.72
GST (820) 1,159.02 743.71
Equity
Retained Earnings (960) 0.00 6,391.10
Total 41,848.30 41,848.30 87,833.18 87,833.18

Print Export

FIGURE 12.2 Trial balance

Source: © Xero Limited.

Typically, we divide reports into two major categories: management reports, which are used within
the organisation, and general purpose financial statements, which are distributed externally. Management
reports tend to be far more detailed in terms of content, and are not intended for sharing outside the
organisation. General purpose financial statements are constructed in accordance with the requirements
of the relevant accounting standards and contain far less detailed information, but are freely available to
a wider range of users.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 541
 The objective of the general ledger and financial reporting cycle is to synthesise and report data that
accurately represents business transactions and activities. In order to achieve this objective, budgets must
be accurately and completely determined and recorded, and transactions extracted and posted must be
complete and accurate. In addition, any adjustments that are required must be made prior to financial
reporting taking place. Any financial report that is based on accrual accounting assumptions can only be
relied upon if it is generated using correctly adjusted data.
An exception is where an operational report (e.g. a simple transaction listing) is required by manage-
ment — basic reports can be generated at any time after a transaction is recorded; it is not necessary to
wait until end-of-period adjustments have been completed. These types of detailed reports usually extract
and report data directly from more detailed subsidiary ledgers (e.g. accounts receivable and cash sales)
rather than the summarised general ledger. A description of documentation flowing through the general
ledger and financial reporting cycle is presented in figure 12.3.

Strategic implications of the general ledger and financial

reporting cycle
The strategic implications of the general ledger and financial reporting cycle revolve around two main
areas. The first is to do with the need for good decision making within the organisation. If management
relies upon reported data that is invalid, or not timely, accurate or complete, inevitably decision-making
performance will be compromised. An additional issue is the design of reports. Too much data can lead
to an inability for the reader to comprehend the content. Poorly arranged data can be misleading, and
a seemingly simple issue like selecting the appropriate font size or column heading has implications in
terms of the understandability of the report. While there is no perfect solution to report design issues, it
is important for designers of financial reports to consider report aesthetics, in addition to data content,
when designing reports. Poor reports lead to poor decision making, which can lead to eventual business
failure; high-quality decision making requires good data and comprehensible reports. The second area
is equally serious. External reports are distributed to corporate regulators, analysts and investors, among
others. Errors in financial reporting can lead to problems such as incorrect market pricing of company
shares, inequitable increases in the cost of capital, inability to access capital markets and the potential
for prosecution if corporate laws are breached.

12.2 Technologies underpinning the general ledger

and financial reporting cycle
LEARNING OBJECTIVE 12.2 Evaluate common technologies underpinning the general ledger and
financial reporting cycle.
There are a number of technologies suitable to support activities within the general ledger and financial
reporting cycle and improve the overall functioning of the cycle. A range of data management tools are
available to help improve the ability to transfer, analyse and report financial data.
Enterprise resource planning (ERP) systems assist with integrating the general ledger into the oper-
ational cycles that precede general ledger and financial reporting processes in the overall business trans-
action cycle. The general ledger links back into most areas within the organisation, so an ERP system
acts to improve enterprise data integration and facilitate stronger controls over the extraction and posting
of data from subsidiary ledgers.
A robust, user-friendly report-generating tool such as Cognos or Crystal Reports is essential for the
production of both ad hoc and standard financial reports. These business intelligence tools typically pro-
vide a simplified user interface to allow interrogation of the underlying data and data dictionary, and the
creation of reports using a drag-and-drop-style interface. The deployment of these user-friendly tools
is particularly useful in an environment where end-users of financial systems take responsibility for
designing and producing their own financial reports.

542 PART 3 Systems in action

 Expenditure
cycle

Revenue
cycle
Purchase
invoice
Cash
remittance
advice
Vendor Purchases Cash
invoices journal receipts
journal

Miscellaneous
documents

Cheques Accounts receivable

subsidiary ledger
General
journal
Miscellaneous Accounts payable
documents subsidiary ledger
Sales
Cash invoice
disbursements
journal
General
journal Sales
journal
General ledger
and financial
reporting cycle

Cash HR
Production Production disbursements management &
Payroll
cycle costs journal payroll cycle

Source Journals and

documents ledgers

FIGURE 12.3 Documentation flowing through the general ledger

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 543
 Access to online banking is helpful in terms of being able to monitor and reconcile cash transactions
more easily. Access to online banking can also be helpful for organisations that wish to automate bank
reconciliations. The ability to download files in electronic format directly from a bank website presents
an opportunity to compare bank statement and cash transaction files electronically, improving both the
timeliness and accuracy of bank reconciliations.
As described in chapter 6, eXtensible Business Reporting Language (XBRL) is a data standard
used when generating financial reports. The importance of this standard is that it allows semantics,
or meaning, to be embedded within strings of financial data, allowing more in-depth analysis to be
conducted by users or recipients of the data. This meaning is conveyed by inserting embedded tags
that identify where separate pieces of data start and end within strings of data. Corporate regulators
worldwide are gradually moving towards mandating XBRL data for corporate filings and reporting.
Detailed information about the use of XBRL is available at www.xbrl.org/au. The Standard Busi-
ness Reporting website (www.sbr.gov.au) has additional information on Australian business reporting
trends and standards. An example of how XBRL is used to add meaning to text data is shown in
figure 12.4.

Text string: 24072009PAR034523897456200

Text string with XBRL tags inserted: <date>24072009<customer_id>PAR0345
<invoice_#>23897<invoice_total$>456200.

FIGURE 12.4 XBRL example

AIS FOCUS 12.1

Storm clouds ahead: some pros and cons of data in the cloud
Cloud computing is essentially the current variant on outsourcing, with organisations paying for vir-
tual data storage managed and owned by an external company. Conceptually, cloud computing means
you use somebody else’s infrastructure to store your data, and they provide your access through the
internet. If you’re using iCloud or Dropbox, you’re engaging in cloud computing.
The main reason for this shift is to more tightly control costs and scalability. Expectations around
accessibility of corporate data have changed considerably over the past decade. Accounting data is
no longer only delivered via a company network to a set of corporate PCs; smartphones, tablets and
24/7 data on demand are here to stay. For an individual firm, the cost of servicing this demand using
in-house IT is quite high. The main reason to move data to the cloud is to simultaneously reduce costs
and gain scalability to cope with demand peaks and troughs.
The core issue with cloud-based accounting data is access control and security. Companies cannot
afford for accounting data security to be breached — this important corporate resource must be
kept totally secure. When considering the outsourcing of data storage, a primary concern should
be around the location, authenticity and longevity of the provider. All these issues around data
­sovereignty point to the need for careful vendor selection. Location is particularly important, as data
privacy practices and principles are determined by the country of domicile of the cloud provider.
Forrester Research (http://heatmap.forrestertools.com) publishes a ‘heat map’ showing privacy and
data protection by country. Forrester assigns country ratings ranging from those with no restrictions
(China, Malaysia) through to minimal restrictions (India, Russia, United States), some restrictions
(Australia, Canada, Mexico) and the most restrictions (Germany, Norway, Finland). Forrester also
notes those countries where government surveillance is at a level that will potentially impact privacy
(Russia, China, Thailand, Singapore). Stories are already surfacing of situations where cloud providers
have shut up shop at short notice, leaving their clients with no data, no recovery plan and little legal
protection. Cost control and scalability are good reasons why we would use a cloud provider for data
storage; however, these benefits do not come free — downside risks are considerable and must be
carefully assessed.

544 PART 3 Systems in action

12.3 Data and decisions in the general ledger and
financial reporting cycle
LEARNING OBJECTIVE 12.3 Recognise general ledger and financial reporting cycle data and key
general ledger and financial reporting business decisions.
A range of data are both produced and consumed by activities within the general ledger and finan-
cial reporting cycle. The actual data stores are documented in detail later in this chapter. This section
describes the general purpose and types of data that the general ledger and financial reporting cycle
requires. The business decisions made during the life of the general ledger and financial reporting cycle
are also discussed here.

Data and the general ledger and financial reporting cycle

Budget data is often initially created based on prior year data, then manually adjusted and entered into
the financial system by finance personnel and operational managers. Budget data is held in the general
ledger chart of accounts, and is used in reporting, largely as a target or benchmark level against which
actual results are compared.
The general ledger and financial reporting cycle initially extracts existing transactional data from
subsidiary ledgers. These subsidiary ledgers include the accounts receivable ledger (which contains
details of customer invoices raised and payments received) and the accounts payable ledger (which
contains details of supplier invoices received and payments approved and made). The payroll data
store provides details of salary and wage transactions. The raw materials, labour and overheads data
stores from the production cycle provide details of production costs incurred. The general ledger
uses all this transactional data to create summarised transactions in the accounts within the general
ledger. These general ledger accounts are conventionally referred to as the chart of accounts for the
organisation.
A typical general ledger account code will contain a string of indicators representing items such
as the transaction type (e.g. revenue, expense or equity), the division or section of the organisation
the transaction relates to, and the nature of the transaction. As an example, a general ledger code of
41235602132801 may represent:

4 = Expenditure
12 = Office supplies
356 = Paper
02 = Victorian branch
13 = Melbourne
28 = Finance department
01 = CFO division.

Any transaction coded with this number would be accumulated and stored in the same general ledger
account. This coding structure would permit data extraction and reporting based on any of the indicators
included. For this example, it would be possible to report all paper purchased, or all expenditure, or
all office supplies expenditure, or all costs for the division, department or branch, or any combination
of these items. Given this code structure, however, it would not be possible to report on purchases of
coloured paper separately from white paper, nor would it be possible to report on the purpose for which
the paper was used, that is, the job number or activity undertaken using the paper. An example showing
chart of account categories is presented in figure 12.5.
The chart of accounts establishes the basis upon which reports can be generated; a fully flexible chart
of accounts would include an indicator for every possible dimension that the transaction may conceiv-
ably need to be reported on. In practice, however, there is a trade-off — the more digits a general ledger

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 545
 account number contains, the more likely data processing errors become. General ledger account codes
are added to every transaction prior to it being processed into the subsidiary ledger during the oper-
ational cycles. The purpose of the general ledger is to extract these transactions and their associated
account numbers, then summarise and transfer the data into the general ledger. A well-designed chart
of accounts will support diverse reporting requirements while maintaining an acceptably low data entry
error rate. Adoption of any alternative costing or reporting requirements, such as activity-based costing,
will increase the number of tags, or indicators, needed to code transactions accurately into the general
ledger accounts.

Alison Parkes
L & E Bicycles
Dashboard Accounts Payroll Reports Contacts Settings

General Settings ›

Chart of Accounts
Add Account Add Bank Account Print PDF Import Export

All Accounts Assets Liabilities Equity Expenses Revenue Archive

What’s this?

Delete Archive Change Tax Rate No accounts selected Search

Code Name Type Tax Rate YTD

Australia Bank Bank BAS Excluded 21,275.00

Accounts Receivable
610 Outstanding invoices the company has issued out to the client but has not yet received in Current Asset BAS Excluded 17,080.00
cash at balance date.
Prepayments
620 Current Asset BAS Excluded 0.00
An expenditure that has been paid for in advance

Inventory
630
Value of tracked items for resale.
Inventory BAS Excluded 21,405.45

Office Equipment
710
Office equipment that is owned and controlled by the business
Fixed Asset GST on Capital 0.00

Less Accumulated Depreciation on Office Equipment

711 The total amount of office equipment cost that has been consumed by the entity (based Fixed Asset BAS Excluded 0.00
on the useful life)

Computer Equipment
720
Computer equipment that is owned and controlled by the business
Fixed Asset GST on Capital 0.00

Less Accumulated Depreciation on Computer Equipment

721 The total amount of computer equipment cost that has been consumed by the business Fixed Asset BAS Excluded 0.00
(based on the useful life)

FIGURE 12.5 Chart of accounts

Source: © Xero Limited.

The only new data created by the general ledger and financial reporting cycle are general journal
entries. Although small in volume, these adjusting journals can have a huge financial impact on the
financial results subsequently reported. General journal data is typically stored in a separate journal
voucher data store, as well as in the relevant general ledger accounts.
Data produced by the general ledger and financial reporting cycle are used by all levels of man-
agement within the organisation and by investors, analysts and regulators external to the organisation.
Access to financial data usually occurs by means of paper or electronic reports for users within the
organisation. External reporting has traditionally been paper based only, with recent augmentation by
electronic reporting.

546 PART 3 Systems in action

 AIS FOCUS 12.2

Online recruiter uses Xero for accounting online

‘Running our accounts online with Xero saves us money, it increases our control, access is easy, and
there is guaranteed security,’ says David Johnson, the Financial Director of BlueGlue.
BlueGlue revolutionised online recruitment with its entirely online outsourced service for IT and
­technology-related businesses. Practising what it preaches, BlueGlue wanted to manage its entire busi-
ness online including the accounts. David Johnson explains that this wasn’t possible until he discovered
Xero.
The recruitment company was growing fast, and BlueGlue had reached the stage where David needed
an extra pair of hands to help with the accounts. He realised the current PC-based software would not
cope with the growing company’s accounting demands. ‘It is not set up for 2 (or more) users to access
the system from different locations  .  .  .  I knew that the solution was to have an online accounting system,
so that both the bookkeeper and I (and anyone else that needed to) could access the SAME accounting
information from anywhere.’ David spent time investigating different solutions, and online accounting
software, and ultimately he chose to implement Xero.
David was one of the first Xero users in the UK and is very impressed with what it can do. ‘As an
accountant myself, I want to be able to get detail and export data to Excel to manipulate it how I want
to. But at the same time, I also want the system to be extremely easy to use for sending out invoices or
reconciling bank accounts; and I want my fellow directors to be able to access management information
directly.’
It has been the Dashboard access and presentation of the cashflow in Xero that has impressed the
Managing Director the most. He can instantly view easy to read graphs and charts showing exactly
where the business is in terms of who owes the company money, and can run simple P&L reports and
monthly comparisons. It has also freed up David’s time as he is no longer continually asked for financial
information as the Managing Director can access Xero directly as needed.
Source: Adapted from http://business.bt.com/btbassets/pdf/BlueGlue.pdf.

General ledger and financial reporting cycle business

decisions
Process business decisions are made from several different perspectives during the general ledger and
financial reporting cycle. Budget decisions relating to the initial establishment of budget levels and the
subsequent monitoring and adjustment of budgets require a good understanding of both the operational
pragmatics of the organisation and the financial performance aspirations of senior management. Typical
budget decisions include the following.
•• Budget level — budgets can be set at a range of levels. Many organisations budget down to a level
known as ‘line item’ where budgets are set for each different type of revenue and expense for each
division as contained in the chart of accounts. An alternative is to set higher level budgets where items
such as office expenses or production costs may be aggregated. Although more aggregate budgets
are easier to plan, their usefulness during monitoring of performance is limited due to the lack of
information they provide.
•• Budget breakdown — budgets can be established with an annual total, or they can be broken down
into months. The degree of granularity at which the budget is set determines how useful the budget
targets will be during performance monitoring. If an annual budget is set, month-by-month monitoring
could be misleading when variances are considered. An additional consideration is the behaviour of
the item being budgeted; not all revenue and expenses divide evenly into 12 over a fiscal year. Using
an expenditure example, an insurance policy may be paid annually, in which case a month-by-month
budget would show that cost only in the month in which it is expected the policy would be renewed.
The example in figure 12.6 contains two report extracts illustrating this issue. In the annual budget
report, a total favourable variance of $24  600 is shown for the year to date, whereas the more detailed

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 547
 month-by-month analysis reveals that a mixture of favourable and unfavourable variances are actually
occurring.
•• Budget targets — setting budget targets requires balance between what is desired in terms of
performance and what is thought to be possible. A good budget target will require some ‘stretch’ to
achieve but not be so high as to be seen as unobtainable. Most budget targets are set during discussion
between managers, and often budget decisions end up being the result of a compromise.
Decisions relating to the creation of general journal adjustments take place during the cycle, and the
data and reports produced by this cycle underpin subsequent decision making within the organisation.
Decisions relating to general journal entries would include consideration of:
•• accounting standards — requires knowledge of relevant standards and understanding of their
applicability to the business
•• accounting policies and procedures — requires knowledge of these procedures and understanding of
their use and intention
•• timing differences for a given accounting period — requires understanding of how accruals and
liabilities are affected by events such as arbitrary period-end dates and transaction cycle cut-off
dates
•• the need to incorporate data from external sources such as bank statements that are not already
captured during the operational cycles.
In addition to these journal adjustment decisions, reports produced by this cycle are used to support
decision makers within the organisation. Common examples of these reports include:
•• profitability analysis for the organisation or a division
•• analysis of performance for an individual or division (variance analysis)
•• analysis of profitability potential to guide future investment decisions
•• cost management analysis for decision making.

Annual budget example

Budget vs actual report 30 September 2015

Budget Actual Variance

Insurance 15  000 0 15  000 (F)

Electricity 8  000 4  800 3  200 (F)

Consumables 12  000 5  600 6  400 (F)

Total 35  000 10  400 24  600 (F)

Month-by-month budget example

Budget vs actual report 30 September 2015

July August September

Budget Actual Variance Budget Actual Variance Budget Actual Variance

Insurance 0 0 0 0 0 0 0 0 0

Electricity 0 0 0 2  000 2  900 (900) 0 0 0

Consumables 1  000 950 50 1  000 1  020 (20) 1  000 1  240 (240)

Total 1  000 950 50 3  000 3  920 (920) 1  000 1  240 (240)

FIGURE 12.6 Budget analysis — annual vs month-by-month

548 PART 3 Systems in action

12.4 General ledger and financial reporting cycle
documentation
LEARNING OBJECTIVE 12.4 Summarise and prepare documentation synthesising the primary activities
in the general ledger and financial reporting cycle and the data produced by these activities.
The general ledger and financial reporting cycle is documented in the following section as a series of
diagrams with increasing amounts of detail. An overview of these general ledger and financial reporting
cycle diagrams is shown in figure 12.7.

General ledger and financial reporting cycle context

The context diagram of a typical general ledger and financial reporting cycle is depicted in figure 12.8.
The general ledger and financial reporting cycle involves direct interaction with entities outside the
organisation that read and use the general purpose financial statements produced by this cycle, and with
the bank to obtain data related to bank account transactions. Within the organisation, the general ledger
and financial reporting cycle interacts with the production, human resource and payroll, expenditure and
revenue cycles as shown in figure P3.1, along with managers of operational departments. Details of the
logical data flows depicted in the general ledger and financial reporting context diagram are contained
in table 12.1.

General ledger and

Context diagram
financial reporting
– figure 12.8
process

Level 0 1.0 2.0 3.0 4.0

logical diagram Prepare budgets Update general Record GL Produce reports
– figure 12.9 ledger adjustments

1.1 1.2 2.1 2.2 3.1 3.2 4.1 4.2

Determine Record Extract & Post Prepare Post Produce Produce
budget budget validate transactions adjustment adjustment management financial
values details data journals journals reports statements

Level 1 logical diagram – Level 1 logical diagram – Level 1 logical diagram – Level 1 logical diagram –
figure 12.10 figure 12.14 figure 12.19 figure 12.24
Process map – figure 12.11 Process map – figure 12.15 Process map – figure 12.20 Process map – figure 12.25
Physical DFD – figure 12.27
Flowchart – figure 12.28

FIGURE 12.7 General ledger and financial reporting diagrammatic overview

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 549
 Various
departments

(11)
(5)
(45)
(3)
(9) (47)
Production
cycle

General ledger (20)

HR management
(26) and financial
and payroll cycle
reporting cycle

(37)
Bank
(17) (50)

(24)
Expenditure
cycle
Revenue External users
cycle

FIGURE 12.8 General ledger and financial reporting cycle context diagram

TABLE 12.1 Description of logical data flows in the general ledger and financial reporting cycle

Typical data Typical data

Flow # source destination Data description Explanation of the logical data flow

Process 1.0 Prepare budgets

1 This flow takes place physically between the budget officer and the computer; it happens
within the 1.0 bubble in the logical diagram.

2 Prior Budget officer Details of prior totals The computer extracts historical totals for each of
transaction for revenue and the revenue and expenditure accounts in the general
history expenditure items ledger.

3 Prior Operational Prior revenue and The revenue and expenditure totals have been loaded
transaction departments expenditure items into a worksheet and are distributed to the relevant
history embedded in a operational departments.
proforma budget
worksheet

4 This flow takes place physically between the budget officer and the computer; it happens
within the 1.0 bubble in the logical diagram.

5 Operational Budget manager Details of adjusted The operational managers responsible for the various
departments budget estimates departments consider the proforma worksheets and
adjust budget items if necessary.

550 PART 3 Systems in action

 Typical data Typical data
Flow # source destination Data description Explanation of the logical data flow

6 Operational Budget manager Trigger for next Once budget values have been adjusted, the budget
departments process details are ready to be input into the computer (not
necessary in a level 0 diagram).

7 This flow takes place physically between the budget officer and the computer; it happens
within the 1.0 bubble in the logical diagram.

8 Operational General ledger Details of approved Once budgets have been checked and approved,
departments data store adjusted budget the budget data are recorded against the appropriate
estimates general ledger accounts.

9 General ledger Operational Details of approved Department managers are advised of finalised
data store departments adjusted budget approved budget details.
estimates

10 This flow takes place physically between the budget officer and the computer; it happens
within the 1.0 bubble in the logical diagram.

11 Operational Budget officer/ Approval of finalised Operational managers positively confirm their
departments manager budgets acceptance of the finalised budget amounts.

12 This flow takes place physically between the budget officer and the computer; it happens
within the 1.0 bubble in the logical diagram.

13 Operational General ledger Details of approved Once final budgets have been accepted and
departments data store final budget estimates approved, the status of the budget data is updated to
‘approved’.

14 This flow takes place physically between the computer and the budget manager; it happens
within the 1.0 bubble in the logical diagram.

15 This flow takes place physically between the budget officer and the computer; it happens
within the 1.0 bubble in the logical diagram.

16 Prepare Update general Final budget estimates Once the budget has been finalised for the year,
budgets ledger ongoing revenue and expenditure transactions can
be recorded against the relevant general ledger
accounts.

Process 2.0 Update the general ledger

17 Expenditure Computer Subsidiary ledger During the expenditure cycle described in chapter 11,
cycle processing completed transactions related to payments established and
made are posted through to the accounts payable
data store. Once this processing is complete, a
notification is sent to the financial cycle to advise
that posting to the general ledger accounts can
commence.

18 Accounts Computer Details of payments Details of payments approved and scheduled to be

payable data approved and paid are extracted from the accounts payable data
store scheduled store.

19 Accounts Computer Details of payments Details of payments made are extracted from the
payable data made accounts payable data store and validated.
store
(continued)

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 551
TABLE 12.1 (continued)

Typical data Typical data

Flow # source destination Data description Explanation of the logical data flow

20 Production Computer Subsidiary ledger During the production cycle, transactions related to
cycle processing completed production costs are posted through to the relevant
data stores. Once this processing is complete, a
notification is sent to the financial cycle to advise
that posting to the general ledger accounts can
commence.

21 Direct labour Computer Details of direct labour Details of direct labour costs of production incurred
costs data costs are extracted from the direct labour costs data store
store and validated.

22 Raw materials Computer Details of raw material Details of raw material costs incurred are extracted
inventory data costs from the raw materials data store and validated.
store

23 Manufacturing Computer Details of Details of manufacturing overhead costs incurred are

overheads data manufacturing extracted from the manufacturing overheads data
store overheads incurred store and validated.

24 Revenue cycle Computer Subsidiary ledger During the revenue cycle described in chapter 10,
processing completed transactions related to invoices raised and payments
received are posted through to the accounts
receivable data store. Once this processing is
complete, a notification is sent to the financial cycle
to advise that posting to the general ledger accounts
can commence.

25 Accounts Computer Details of invoices Details of invoices raised and cash payments received
receivable data raised and cash are extracted from the accounts receivable data store
store payments received and validated.

26 HR Computer Subsidiary ledger During the HR management and payroll cycle,

management processing completed transactions related to payroll costs are posted
and payroll through to the relevant data stores. Once this
cycle processing is complete, a notification is sent to the
financial cycle to advise that posting to the general
ledger accounts can commence.

27 Payroll master Computer Salary and wage Details of salary and wages payments made are
file payment details extracted from the payroll data store and validated.

28 Extract and Post transactions Trigger for next After all transaction data have been extracted and
validate data process validated, the summarised totals can be posted to
the relevant general ledger accounts in the general
ledger data store (not necessary in a level 0 diagram).

29 Transactional General ledger Summarised validated The transaction totals extracted and validated in the
processes data store transaction totals preceding process are posted into the appropriate
general ledger accounts.

30 Computer Accounts payable Details of transactions Once the accounts payable transactions have been
data store posted to the general posted to the general ledger, their status code in the
ledger subsidiary ledger is updated to ‘posted’.

31 Computer Accounts Details of transactions Once the accounts receivable transactions have
receivable data posted to the general been posted to the general ledger, their status
store ledger code in the subsidiary ledger is updated to ‘posted’.

552 PART 3 Systems in action

 Typical data Typical data
Flow # source destination Data description Explanation of the logical data flow

32 Computer Direct labour Details of transactions Once the direct labour cost transactions have
costs data store posted to the general been posted to the general ledger, their status
ledger code in the subsidiary ledger is updated to ‘posted’.

33 Computer Raw materials Details of transactions Once the raw materials transactions have been
inventory data posted to the general posted to the general ledger, their status code in the
store ledger subsidiary ledger is updated to ‘posted’.

34 Computer Manufacturing Details of transactions Once the manufacturing overhead transactions have
overheads data posted to the general been posted to the general ledger, their status code in
store ledger the subsidiary ledger is updated to ‘posted’.

35 Computer Payroll data store Details of transactions Once the payroll transactions have been posted to
posted to the general the general ledger, their status code in the subsidiary
ledger ledger is updated to ‘posted’.

36 Update general Record Summarised Once all transactions have been posted to the general
ledger general ledger transaction data ledger, any accounting adjustments necessary can be
adjustments processed.

Process 3.0 Record general ledger adjustments

37 Bank Accounting staff Bank statement The bank supplies details of transactions from the
transaction details bank accounts on a regular basis.

38 Accounting Journal voucher Details of general Accounting staff prepare and input details of the
staff data store journal entries general journal entries required.

39 Senior Journal voucher Approval for general Details of the proposed general journal entries are
accounting data store journal entry sent to senior accounting staff for approval.
staff

40 Prepare Post adjustment Trigger for next After journal entries have been approved, the relevant
adjustment journals process general ledger accounts in the general ledger data
journals store can be updated (not necessary in a level 0
diagram).

41 Computer Journal voucher Details of approved Periodically, the computer extracts details of all the
data store general journal entries approved, but not yet processed, journal entries from
the journal voucher data store.

42 Computer General ledger Details of approved Approved general journal entries are posted to the
data store general journal entries relevant general ledger accounts.

43 Computer Journal voucher Posted general journal The status of the general journal voucher is updated
data store entries to ‘processed’.

44 Record Produce reports Posted general journal Once the adjusting entries have been approved and
general ledger entries posted, reports can be generated.
adjustments

Process 4.0 Produce reports

45 Operational Accounting staff Ad hoc report requests Operational department managers submit requests for
departments reports on an ad hoc basis.

(continued)

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 553
TABLE 12.1 (continued)

Typical data Typical data

Flow # source destination Data description Explanation of the logical data flow

46 General ledger Computer General ledger data The computer extracts the data required to populate
data store the requested reports from the general ledger data
store.

47 Computer Operational Requested report data Once an ad hoc report has been generated, it is sent
departments to the department that requested it.

48 Produce Produce financial Trigger for next Once the management reports have been generated
management statements process and examined, the general purpose financial
reports statements can be produced (not necessary in a
level 0 diagram).

49 General ledger Computer General ledger data At regular predetermined intervals, the computer
data store extracts the data required to populate the general
purpose financial statements from the general ledger
data store.

50 Computer External Financial statements Once the general purpose financial statements have
users/senior data been generated, they are distributed to external users
management and to senior management.

General ledger and financial reporting cycle logical

data flows
Figure 12.9 depicts a level 0 logical DFD. This diagram shows the entire general ledger and finan-
cial reporting cycle in greater detail than that depicted in the context diagram. The logical DFD is an
exploded version of the context diagram, with the bubble described as ‘general ledger and financial
reporting cycle’ in the context diagram broken down into four processes. The logical diagram at level 0
helps us to analyse and understand the general ledger and financial reporting cycle in its entirety. It
depicts the chronology of the cycle, the data stores and external entities involved in each of the pro-
cesses and the interactions between these processes, entities and data stores. The logical level 0 diagram
in figure 12.9 is itself broken down to describe even lower levels of detail in the logical diagrams in
figures 12.10, 12.14, 12.19 and 12.24 later in this chapter. Details of the logical data flows depicted in
this diagram are contained in table 12.1.

Description of logical data flows in the general ledger and

financial reporting cycle
A logical DFD contains only those data flows relating to inputs and outputs of the activities contained
within each of the processes, as opposed to the details of all interactions between entities as depicted
in a physical DFD. As a result, the number of flows in a logical DFD is always less than those that
would be shown in a physical DFD for the same process. To illustrate this, compare figures 12.10
and 12.27, which both show exactly the same process; however, figure 12.10 is a logical description
whereas figure 12.27 is a physical description. In order to maintain consistency of documentation refer-
ences, the larger number of flows contained in the physical DFD of process 1.0 shown in figure 12.27
are numbered sequentially in table 12.6. The numbering of the subset of data flows for process 1.0
depicted in the logical diagram shown in figure 12.10 and documented in table 12.1 are therefore not
sequential.

554 PART 3 Systems in action

 (3)

Various
departments (11)
1.0
(5) Prepare
budgets
(9)

Production Expenditure
cycle Revenue (2)
cycle Manufacturing
(16) cycle
overheads (8)
(17)
HR management (20) (24)
and payroll (23) (13)
cycle (26) 2.0
Update (34)
(18)
the general
(19) Payroll
ledger
(27)
Accounts (30)
payable
(35)
(31) (29) General
(25) ledger

Bank
(36)
Accounts (32) (33)
(21)
receivable (22)

Raw materials
Direct labour
inventory (37)
costs

(42)
3.0
Record general
(39) ledger
adjustments
(38)
(41) (46)

(44) (49)
(43)
Journal
voucher

4.0
Produce
(45) reports

(50)

Various (47)
External users
departments

FIGURE 12.9 General ledger and financial reporting cycle level 0 logical diagram

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 555
12.5 General ledger and financial reporting cycle
activities and related risks and controls
LEARNING OBJECTIVE 12.5 Assess risks and compose control plans pertinent to the primary activities
in the general ledger and financial reporting cycle.
The activities within the general ledger and financial reporting cycle and the associated risks and con-
trols are described under the four general ledger and financial reporting cycle headings below. Following
the activity descriptions for each of the processes are the level 1 DFD and process map for the process
and a table summarising the activities, risks and controls within the process.

Prepare budgets — activities, risks and controls

Process 1.0, prepare budgets, comprises the following activities.
Determine budget values
The general ledger and financial reporting cycle begins with the creation of an operational budget. Note
that differing phases of the general ledger and financial reporting cycle run concurrently; for example,
while budgeting is taking place, the finance staff will still be recording general ledger adjustments and
the transaction cycles will still be processing and generating data. This sequencing is identical to that
experienced in other cycles. For example, in the revenue cycle the sales phase runs continuously, as does
the shipping and billing phases; however, to improve understandability we document each cycle as a
linear procedure, with activities happening in sequence. The cycle documentation is drawn to represent
one single cycle from start to finish; however, multiple transaction cycles will always run simultaneously.
Budgets are planning estimates of future revenue and expenditure items, and are an important manage-
ment tool. Budgets are used for planning and for comparison against actual performance for monitoring and
control purposes. There are several common methods used to construct a budget. Budgets may be incremen-
tally calculated by referencing historical transactions and indexing by some estimated percentage amount,
or by analysing proposed activity levels for the future period and then calculating estimated revenue and
expenditure based on those predicted activity levels. Another alternative is zero-based budgeting where prior
results are not used as a starting point for future estimates at all; rather, all budget values are based on future
estimates only. Zero-based budgeting requires that each estimate be individually justified by management,
and is not concerned with whether the total budget is increasing or decreasing.
In addition to the operational budgets described above, organisations generally prepare a capital
expenditure budget where a central pool of funding is allocated to major works and projects. Capital
expenditure budgets are generally allocated through a competitive application process, with project pro-
posals ranked and funded on the basis of potential to return value to the business.
Where prior transactional data is used to form the operational budget, the computer would extract totals
for each of the revenue and expenditure accounts in the general ledger to establish a starting point for deter-
mining future budget estimates. Once the revenue and expenditure totals have been extracted, they need to be
distributed to the relevant operational departments, either electronically in a form similar to an Excel spread-
sheet, or on paper. Proforma budgets are usually prepared on a month-by-month basis for the upcoming fiscal
year. The operational managers responsible for the various departments would consider the proforma work-
sheets and adjust budget items if necessary. These adjustments are often required due to local knowledge of
changes in operating conditions that make prior estimates imperfect predictors of future outcomes.
The primary risk when determining budget values is under- or overestimating revenue and expenditure
amounts. Common controls to reduce this risk include requiring independent approval of budget estimates,
and the preparation of estimates by operational managers. Budgets are often aggregated to show department
budget totals and independent approval should be obtained for overall budget totals. The existence of tight
linkages between budget values and performance monitoring is an important control; that is, if managers are
aware that their performance is being monitored and measured against budget estimates, they are more likely
to provide thoughtful input into the budget estimates and to attempt to meet their budget targets.

556 PART 3 Systems in action

Record budget details
Once budgets have been checked and approved, the budget totals can be input into the central computer
to establish the budget levels for future periods against the appropriate general ledger accounts.
Operational managers need to be aware of final budget details, as these form their performance targets
for future periods. This is particularly important where managers may not have determined the final
budget estimates; these managers need a chance to consider budget estimates before the budget is final-
ised. The finalisation of budgets is an interactive process involving both senior management and oper-
ational staff. Operational managers should positively confirm their acceptance of the finalised budget
amounts. As these amounts will be used to monitor and manage their future performance, it is important
to establish the commitment and buy-in by managers to the budgeted amounts. Once final budgets have
been accepted and approved by senior management, the ongoing revenue and expenditure transactions
can be recorded against the relevant general ledger accounts for those time periods.
The primary risk related to recording budgets is data entry errors. This risk is particularly relevant
where budgets are created and revised using Excel spreadsheets or similar and manually keyed into the
computer, a practice that is quite common. Controls to reduce this risk include adding edit or reason-
ability checks on input, for example, producing a warning message if budget estimate varies by more
than a fixed percentage from last year’s budget. The use of batch totals is also helpful, especially where
budgets are being entered at line-item level. A final common control is requiring independent approval
of final budget inputs by senior management.
Prepare budgets — DFD
The level 1 DFD in figure 12.10 contains a lower level of detail about the first process represented in the
level 0 logical DFD in figure 12.9, prepare budgets. In the same way in which the level 0 logical diagram
explodes out the ‘general ledger and financial reporting cycle’ bubble in the context diagram, the level 1
diagram explodes out the ‘prepare budgets’ bubble.
Summary description of activities in preparing a budget
Table 12.2 summarises the activities, risks and controls when preparing a budget as depicted in the level 1
DFD in figure 12.10 and and process map in figure 12.11. Table 12.1 explains the logical data flows depicted
in the logical DFD in figure 12.10 and the process map in figure 12.11. Exploring the diagram in conjunction
with the material contained in the tables will assist in improving your understanding of the process depicted.

Update the general ledger — activities, risks and controls

Process 2.0, update the general ledger, comprises the following activities.
Extract and validate data
Once processing in the subsidiary ledgers has been successfully completed, the revenue, expendi-
ture, production, and HR management and payroll cycles send notifications to the financial cycle. The
summarised details from all the subsidiary transaction systems created by these other cycles are then
extracted for posting into the general ledger. This is typically an automated batch job usually run at the
end of the business day in preparation for the next business day.
During the expenditure cycle described in chapter 11, transactions related to payments established and
made are posted to the accounts payable data store. Once this processing is complete, a notification is sent
to the financial cycle to advise that posting to the general ledger accounts can commence. Details of pay-
ments approved and scheduled to be paid are extracted from the accounts payable data store. This flow
usually occurs on a daily basis, so only the totals for the preceding day would be extracted. A more detailed
listing of these transactions is retained for each supplier in the accounts payable data store. Details of pay-
ments made are extracted from the accounts payable data store and validated. This flow usually occurs on a
daily basis, so only the totals for the preceding day would be extracted. A more detailed, but still summar-
ised, listing of these transactions is retained for each supplier in the accounts payable data store. A com-
plete detail of each individual payment transaction is held in the cash payments data store.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 557
 (2)

1.1
Determine
budget General
values ledger

(3)

(6) (8)
(5) (13)

Various 1.2
departments Record
(11)
budget
details

(9) (16)

2.0
Update
general
ledger

FIGURE 12.10 General ledger and financial reporting cycle level 1 logical diagram — process 1.0
Prepare budgets

TABLE 12.2 Activities in preparing a budget

Usually Typical risks

Activity # Activity conducted by Activity description encountered Common controls

1.1 Determine Budget staff, Determine budgets for revenue Under/ Independent approval of budget
budget department and expenditure items for the overestimating estimates
values managers following period. This may revenue Preparation of estimates by
be calculated by referencing and expenditure operational managers
historical transactions and Aggregation of department
indexing by some estimated budget totals and independent
percentage amount, or by approval of overall budget
analysing proposed activity totals
levels for the future period Tight linkages between budget
and then calculating estimated values and performance
revenue and expenditure based monitoring systems
on predicted activity levels.

1.2 Record Budget The approved budget totals are Data entry Edit checks on input
budget officer/various input into the central computer errors Reasonability checks (see
details departments to establish the budget levels example in figure 12.12)
for future periods. Using batch totals
Independent approval of final
budget inputs

558 PART 3 Systems in action

Budget manager
Approve
Receives adjusted Advised budget
adjusted
budget is finalised
budget?

Budget officer

Requests Receives budget Receives and inputs Receives finalised Records approved Advised budget
transaction worksheet approved budget budget report budget is finalised
history data
Computer

Creates budget Creates finalised Creates final

worksheet budget approved budget
departments
Operational

Receives budget Adjust budget Receives finalised Budget

worksheet items? budget report acceptable?

FIGURE 12.11 General ledger and financial reporting cycle process map — process 1.0 Prepare budgets

Overall Budget
Budget Summary
L & E bicycles
July 2015 to July 2015

Account Jul-15

Income
Sales 36,000
Total Income 36,000

Less Cost of Sales

Cost of Goods Sold 27,000
Total Cost of Sales 27,000
Gross Profit 9,000

Less Operating Expenses

Advertising 500
Bank Fees 20
Depreciation 280
Insurance 15
Light, Power, Heating 150
Printing & Stationery 50
Total Operating Expenses 1,015
Total Expenses 1,015
Net Profit 7,985

Print Export

FIGURE 12.12 Internal control — budget report used for reasonability check
Source: © Xero Limited.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 559
 During the production cycle, transactions related to production costs are posted to the relevant data
stores. Once this processing is complete, a notification is sent to the financial cycle to advise that posting
to the general ledger accounts can commence. Details of direct labour costs of production incurred are
extracted from the direct labour costs data store and validated. This flow usually occurs on a daily basis,
so only the totals for the preceding day would be extracted. A detailed listing of these transactions is
retained in the labour costs data store. Details of raw material costs incurred are extracted from the raw
materials data store and validated. This flow usually occurs on a daily basis, so only the totals for the
preceding day would be extracted. A detailed listing of these transactions is retained in the raw materials
inventory data store. Details of manufacturing overhead costs incurred are extracted from the manufac-
turing overheads data store and validated. This flow usually occurs on a daily basis, so only the totals for
the preceding day would be extracted. A detailed listing of these transactions is retained in the manufac-
turing overheads data store.
During the revenue cycle described in chapter 10, transactions related to invoices raised and
payments received are posted to the accounts receivable data store. Once this processing is com-
plete, a notification is sent to the financial cycle to advise that posting to the general ledger accounts
can commence. Details of invoices raised and cash payments received are extracted from the
accounts receivable data store and validated. This flow usually occurs on a daily basis, so only the
totals for the preceding day would be extracted. A more detailed, but still summarised, listing of
these transactions by customer is retained in the accounts receivable data store. A complete detail of
each individual transaction is held in the sales data store (invoices raised) and the cash receipts data
store (payments received). Figure 12.13 contains an example of how data may appear in each of these
journals. Note the data becomes progressively more summarised as it moves though the relevant
journals.
During the HR management and payroll cycle, transactions related to payroll costs are posted through
to the relevant data stores. Once this processing is complete, a notification is sent to the financial cycle
to advise that posting to the general ledger accounts can commence.
Details of salary and wages payments made are extracted from the payroll data store and validated.
This flow usually occurs on a weekly, fortnightly or monthly basis, so only the totals for the preceding
payroll runs would be extracted. A more detailed listing of these transactions is retained for each
employee in the payroll data store.
After all transaction data have been extracted and validated, the summarised totals can be posted to
the relevant general ledger accounts in the general ledger data store.
The primary risks related to extracting and validating data are incomplete and inaccurate data.
Common controls used to reduce this risk include the use of batch totals (e.g. to check sales totals) and
hash totals (e.g. to check customer numbers). In addition, most accounting systems use ledger control
accounts that detail the total posted from each subsidiary ledger and compare those totals back to the
relevant subsidiary ledgers. Generating automated system exception reports that identify any problems
encountered during extraction and validation should form part of the daily processing routines for finan-
cial systems.

Post transactions
The verified summarised transaction data are posted to the relevant general ledger accounts. This is also
automated and run immediately following validation of the data in the previous activity. Once trans-
actions have been successfully posted to the relevant accounts, the transactions contained in the sub-
sidiary ledger data stores are updated with a status code to indicate that they have been posted to the
general ledger accounts.
Once all transactions have been posted to the general ledger, any accounting adjustments necessary
can be processed. The main risk related to posting transactions to the general ledger is inaccurate
updating; use of batch and hash totals act to reduce this risk, as does performing regular control account
reconciliations to assist with detecting any errors.

560 PART 3 Systems in action

 Sales data
Date Invoice # Sales rep ID Customer # Amount
23/9/15 154723897 MLB005 PAR569   1  659

23/9/15 154723898 SYD002 CON002 54  566

23/9/15 154723899 MLB001 OEL021 2  568  948

23/9/15 154723900 MLB001 SMI045   597  821

23/9/15 154723901 SYD011 JON045   86  429

23/9/15 154723902 SYD005 DOW345 1  549  730

23/9/15 154723903 SYD008 DAV498   16  897

23/9/15 154723904 MLB006 LYO345 159  397  054

23/9/15 154723905 MLB015 LEE945   1  230

23/9/15 154723906 SYD003 ZHU564   36  710

23/9/15 154723907 SYD004 BRO983 3  215  667

23/9/15 Total sales 167  526  711

Accounts receivable data

Sales ref # Customer # Amount
154723907 BRO983 3  215  667

154723898 CON002   54  566

154723903 DAV498   16  897

154723902 DOW345 1  549  730

154723901 JON045   86  429

154723905 LEE945   1  230

154723904 LYO345 159  397  054

154723899 OEL021 2  568  948

154723897 PAR569   1  659

154723900 SMI045   597  821

154723906 ZHU564 36  710

Total sales 167  526  711

General ledger data
Amount Amount
Accounts receivable 167  526  711
Sales 167  526  711

FIGURE 12.13 Revenue data posting

Update the general ledger — DFD

The level 1 DFD in figure 12.14 contains a lower level of detail about the second process represented
in the level 0 logical DFD in figure 12.9. This process takes place after the budget has been prepared in
the preceding process and prior to the accounting adjustments made in the following process.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 561
 1.0
Prepare
budgets

HR management Production Expenditure

and payroll cycle cycle cycle (16)

(26) (20) (17)

Revenue
cycle

(24) (23) (27)

2.1
Extract &
(18) validate data (22)
(19) Manufacturing
overheads
(25) (21)
Accounts
Raw materials
payable
Accounts inventory Payroll
Direct labour
receivable
(28) costs

(33) (34)
(32)

(31)
(35)
2.2
(30) Post
transactions

(29)

(36)
General
ledger

3.0
Record
general ledger
adjustments

FIGURE 12.14 General ledger and financial reporting cycle level 1 logical diagram — process 2.0 Update
the general ledger

562 PART 3 Systems in action

 Expenditure cycle
Notifies Updates
posting can transaction
commence status to
‘posted’

Production cycle

Notifies Updates
posting can transaction
commence status to
‘posted’

Updates Updates Updates Updates HR

Computer

expenditure Transactions production Transactions revenue Transactions transactions to Transactions

transactions to validated? transactions to validated? transactions to validated? general ledger validated?
general ledger general ledger general ledger
Revenue cycle

Notifies Updates
posting can transaction
commence status to ‘posted’

Notifies Updates
HR cycle

posting can transaction

commence status to
‘posted’

FIGURE 12.15 General ledger and financial reporting cycle process map — process 2.0 Update the general ledger

Summary description of activities in updating the general ledger

Table 12.3 summarises the activities, risks and controls when updating the general ledger, as depicted in
the level 1 DFD in figure 12.14 and the process map in figure 12.15. Table 12.1 explains the logical data
flows depicted in the logical DFD in figure 12.14 and the process map in figure 12.15. Exploring the dia-
gram in conjunction with the material contained in the tables will assist in improving your understanding
of the process depicted.

TABLE 12.3 Activities in updating the general ledger

Usually Typical risks

Activity # Activity conducted by Activity description encountered Common controls

2.1 Extract and Computer Once processing in the subsidiary Incomplete Batch totals and hash totals
validate data ledgers has been successfully data Using ledger control
completed, the revenue, accounts that detail totals
expenditure, production, and HR posted from each ledger
management and payroll cycles and allow comparison of
send a notification to the financial those totals
cycle. The summarised details
from all the subsidiary transaction Inaccurate Automated system
systems created by these other data exception reports that
cycles are then able to be extracted identify any problems
for posting into the general ledger. encountered during
extraction and validation

(continued)

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 563
TABLE 12.3 (continued)

Usually Typical risks

Activity # Activity conducted by Activity description encountered Common controls

2.2 Post Computer The verified summarised transaction Inaccurate Batch totals and hash totals
transactions data are posted to the relevant updating Regular control account
general ledger accounts. Once reconciliations (see example
transactions have been successfully in figure 12.16)
posted to the relevant accounts,
the transactions contained in the
subsidiary ledger data stores are
updated with a status code to
indicate that they have been posted
to the general ledger accounts.

GST Reconciliation
L & E bicycles
From 1 July 2015 to 31 July 2015
Accruals Basis

GST Collected
GST Period GST Collected Adjustments Filed Unfiled
Opening Balance 3,451.82
1 Jul 15 - 31 Jul 15 3,488.64 6,940.46

Total 3,488.64 0.00 0.00 6,940.46

GST Paid
GST Period GST Paid GST On Imports Adjustments Filed Unfiled
Opening Balance 5,354.55
1 Jul 15 - 31 Jul 15 2,329.62 0.00 7,684.17

Total 2,329.62 0.00 0.00 0.00 7,684.17

GST Account Transactions

Date Transaction Amount
Total 0.00

GST Owing
Opening Balance 0.00
Plus GST Collected and Filed 0.00
Less GST Paid and Filed 0.00
Less Payments Made 0.00
Closing Balance 0.00

GST Account Summary

GST Owing 0.00
Unfiled GST (743.71)
Balance at 31 July 2015 (743.71)

GST Account Balance (743.71)

Print Export

FIGURE 12.16 Internal control — GST reconciliation report

Source: © Xero Limited.

564 PART 3 Systems in action

Record general ledger adjustments — activities, risks
and controls
Process 3.0, record general ledger adjustments, comprises the following activities.

Prepare adjustment journals

At regular intervals a bank reconciliation is completed. The bank supplies details of transactions
from the bank accounts on a regular basis, usually daily, weekly or monthly depending on the
volume of transactions processed. This data consists of all the deposits and withdrawals processed
to the bank accounts, along with details of any bank fees or charges and periodical payments
processed by the bank against the bank account. The bank transaction data could be supplied on
paper, in the form of a bank statement, or online via a download from the bank’s internet banking
facilities.
General journal entries are prepared for any accounting adjustments required. An example of a journal
voucher is shown in figure 12.17. Figure 12.18 shows a typical screen used to input the journal data.
These adjustments typically recognise end-of-period accruals and also capture transactions such as
bank fees or interest charges not captured by transaction processing cycles. All journal entries should
be approved by senior accounting staff to ensure conformance with accounting standards and organ-
isational policies. Accounting staff prepare and input details of the general journal entries required.
General journal data is stored in the journal voucher data store. General journal entries are usually
numbered sequentially and cross-referenced to supporting working papers to enable easy identification
and tracking. Details of the proposed general journal entries should be sent to senior accounting staff for
approval. After journal entries have been approved, the relevant general ledger accounts in the general
ledger data store can be updated.

Australian Information Company

Level 2, 345 Hill Terrace
Melbourne, Vic 3003

Journal voucher No.: 72890

Received from: Date entered: Prepared by: Approved by: Posted by:
Margaret Duns 1/05/15 Jacob Jones Tim Chen XXX

Account code Account title Debit amounts Credit amounts

101 Cash 100

149 Accounts receivable — control 100

Remarks:

FIGURE 12.17 Sample journal voucher

The primary risk when preparing adjusting journals is errors in journal entries. Common controls to
reduce this risk include obtaining independent approval of journal entries by senior accounting staff and
attaching full working papers to support journal entry calculations. Organisations should also document
any assumptions and algorithms relied on when calculating journal amounts and mandate the provision
of source documents where available.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 565
 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Manual Journals ›
New Manual Journal

Draft

Narration Date Auto Reversing Date (optional)

Depreciation June 30 Jun 2021

Default narration to journal line description

Show journal on cash basis reports ?

Amounts are No Tax

Description Account Tax Rate Debit AUD Credit AUD

Depreciation June 416 - Depreciation BAS Excluded 280.00

Depreciation June 711 - Less Accumulated Depreciat... BAS Excluded 250.00

Depreciation June 721 - Less Accumulated Depreciat... BAS Excluded 30.00

Subtotal 280.00 280.00

Add a new line

Total 280.00 280.00

Save as draft Post Cancel

FIGURE 12.18 Journal input screen

Source: © Xero Limited.

Post adjustment journals

Periodically, the computer extracts details of all the approved, but not yet processed, journal entries
from the journal voucher data store. The approved general journal entries are posted to the relevant
general ledger accounts and the status of the general journal voucher is updated to ‘processed’. The
main risk when posting adjusting journals is data entry errors; use of batch totals (to ensure correct
amounts entered) and hash totals (to ensure correct general ledger accounts selected) act to reduce this
risk, as does one-for-one checking of general journal entry inputs. Once the adjusting entries have been
approved and posted, reports can be generated.

Record general ledger adjustments — DFD

The level 1 DFD in figure 12.19 contains a lower level of details about the third process represented in
the level 0 logical DFD in figure 12.9. This process takes place after the transactional data have been
posted to the general ledger accounts in the preceding process and before reports are generated in the
following process.

566 PART 3 Systems in action

 2.0
Update the
general ledger

(36)

3.1 (38)
Prepare
(39)
adjustment
journals
(37)
Bank
(40)
Journal
vouchers

3.2 (41)
Post
adjustment (43)
journals

(42)

General ledger (44)

4.0
Produce
reports

FIGURE 12.19 General ledger and financial reporting cycle level 1 logical diagram — process 3.0 Record
general ledger adjustments

Description of activities in recording general ledger adjustments

Table 12.4 summarises the activities, risks and controls when recording general ledger adjustments, as
depicted in the level 1 DFD in figure 12.19 and the process map in figure 12.20. Table 12.1 explains
the logical data flows depicted in the logical DFD in figure 12.19 and the process map in figure 12.20.
Exploring the diagram in conjunction with the material contained in the tables will assist in improving
your understanding of the process depicted.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 567
 Supplies
Bank transaction
details

Adjusting entries Prepare general Input approved

Accounting staff
required? journals journal entries

Journal entries Approve general

Senior accounting
correct? journals
staff

Updates transaction
Updates general
Computer status to
ledger accounts
‘processed’

FIGURE 12.20 General ledger and financial reporting cycle process map — process 3.0 Record general ledger
adjustments

TABLE 12.4 Activities in recording general ledger adjustments

Usually Typical risks

Activity # Activity conducted by Activity description encountered Common controls

3.1 Prepare Accounting staff A bank reconciliation is completed Errors in Independent approval of
adjustment and general journal entries are journal entries journal entries by senior
journals prepared for any accounting accounting staff
adjustments required. These Attaching full working papers
adjustments typically recognise to support journal entry
end-of-period accruals and calculations
capture transactions such as
Documenting any assumptions
bank fees or interest charges
and algorithms relied on when
not captured by the transaction
calculating journal amounts
processing systems.
Mandating the provision of
source documents where
available

3.2 Post Accounting staff The approved journals are posted Data entry Batch totals to ensure
adjustment to the relevant general ledger errors correct amounts entered (see
journals accounts. example in figure 12.21) and
hash totals to ensure correct
general ledger accounts
selected
One-for-one checking
of general journal entry
inputs

568 PART 3 Systems in action

 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

Manual Journals ›
New Manual Journal

Draft

Narration Date Auto Reversing Date (optional)

Depreciation June 30 Jun 2021

Default narration to journal line description

Show journal on cash basis reports ?

Amounts are No Tax

Description Account Tax Rate Debit AUD Credit AUD

Depreciation June 416 - Depreciation BAS Excluded 280.00

Depreciation June 711 - Less Accumulated Depreciat... BAS Excluded 230.00

Subtotal 280.00 230.00

Add a new line

Total 280.00 230.00

Total is out by: 50.00

Save as draft Post Cancel

History & Notes ?

Show History (0 entries) Add Note

FIGURE 12.21 Internal control — use of batch totals in journal entry

Source: © Xero Limited.

Produce reports — activities, risks and controls

Process 4.0, produce reports, comprises the following activities.
Produce management reports
There are two main triggers to produce management reports. Most organisations have a standard set
of reports that are produced at the end of each accounting period; these are triggered and created auto-
matically by the computer and distributed based on a predetermined list to department staff. The second
trigger for reporting is in response to an ad hoc request from a department. These reports are typically
one-off reports and are often requested to support a particular decision.
Both types of reports are created based on a report specification template that outlines the column
headings, totals required and layout for the required report. This report template is then populated with
the transaction data that fits the requested report parameters. Report data parameters typically include the
start and finish dates of the transactions required, the general ledger account numbers to be reported on,
and the divisions, or operational units, to be included in the report. Additional criteria can also be added

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 569
 to limit the data to that required; for example, reported sales data may be constrained to a particular
geographic region, store or salesperson. An example of a management report is shown in figure 12.22.
Reports may be specified, tested and generated by accounting staff or operational managers, and staff
may have the capability to independently create their own ad hoc reports. Most accounting systems con-
tain basic reporting functionality supporting one-off special-purpose reports along with a standard suite
of reports that can be automatically generated and distributed on a regular basis.

Budget Variance
L & E bicycles
For the month ended 31 July 2015

Actual Budget Var AUD Var % YTD Actual YTD Budget Var AUD Var %

Income
Sales 34,886.36 36,000.00 (1,113.64) –3.1% 34,886.36 36,000.00 (1,113.64) –3.1%
Total Income 34,886.36 36,000.00 (1,113.64) –3.1% 34,886.36 36,000.00 (1,113.64) –3.1%

Less Cost of Sales

Cost of Goods Sold 26,681.75 27,000.00 (318.25) –1.2% 26,681.75 27,000.00 (318.25) –1.2%
Total Cost of Sales 26,681.75 27,000.00 (318.25) –1.2% 26,681.75 27,000.00 (318.25) –1.2%
Gross Profit 8,204.61 9,000.00 (795.39) –9.0% 8,204.61 9,000.00 (795.39) –9.0%

Less Operating Expenses

Advertising 436.36 500.00 (63.64) –12.7% 436.36 500.00 (63.64) –12.7%
Bank Fees 20.00 20.00 0.00 0.00% 20.00 20.00 0.00 0.00%
Depreciation 0.00 280.00 (280.00) –100.0% 0.00 280.00 (280.00) –100.0%
Insurance 13.64 15.00 (1.36) –9.1% 13.64 15.00 (1.36) –9.1%
Light, Power, Heating 159.09 150.00 9.09 6.1% 159.09 150.00 9.09 6.1%
Printing & Stationery 18.18 50.00 (31.82) –63.6% 18.18 50.00 (31.82) –63.6%
Total Operating Expenses 647.27 1,015.00 (367.73) –36.2% 647.27 1,015.00 (367.73) –36.2%
Net Profit 7,557.34 7,985.00 (427.66) –5.0% 7,557.34 7,985.00 (427.66) –5.0%

Layout Options Print Export

FIGURE 12.22 Management report: budget variances

Source: © Xero Limited.

The computer extracts the data required to populate the requested reports from the general ledger data
store. Once a report has been generated, it is sent to the system user who requested it. This can be done
either electronically (email or on screen) or in print. The primary risk related to producing management
reports is using incorrect report parameters or reporting incorrect data. To reduce this risk it is important
to limit report generation functionality to appropriately trained staff, and require independent author-
isation for any new report prior to circulation of that report.
Due to the detailed nature of management reporting, there is also a risk of unauthorised distribution
of financial data as, unlike the general purpose financial statements, these reports are not intended for
use or distribution outside the organisation. Controls to reduce this risk include applying secure privacy
settings on electronic reports limiting ability to print/redistribute reported data and using a document
management system for reports containing sensitive data. In addition, security profiles allowing read-
only access to financial data need to be granted and maintained at an individual staff member level.
Once the management reports have been generated and examined, the general purpose financial state-
ments can be produced.

570 PART 3 Systems in action

Produce financial reports
General purpose financial statements are produced at predetermined intervals and are constructed in
accordance with the relevant accounting standards. Accounting standards are used to create the busi-
ness rules and specifications underlying the financial data and report parameters. When a trigger date
occurs, the reports are automatically produced and distributed, either electronically or on paper. At these
regular predetermined intervals, the computer extracts the data required to populate the general purpose
financial statements from the general ledger data store. Note that any adjustments required should have
already been made to the underlying data; reporting outputs may require formatting or similar presen-
tation manipulation, but the data contents should remain unchanged. Once the general purpose financial
statements have been generated, they are distributed to external users and to senior management, either
electronically or on paper. Electronic distribution of general purpose financial statements can be made
either in a static form such as a PDF file or dynamically via the use of XBRL. Examples of general pur-
pose financial statements are shown in figure 12.23.

Profit and Loss

L & E bicycles
For the month ended 31 July 2015

Trading Income Jul 2015

Sales 34,886.36

Total Trading Income 34,886.36

Cost of Sales
Cost of Goods Sold 26,681.75

Total Cost of Sales 26,681.75

Gross Profit 8,204.61

Operating Expenses
Advertising 436.36

Bank Fees 20.00

Insurance 13.64

Light, Power, Heating 159.09

Printing & Stationery 18.18

Total Operating Expenses 647.27

Net Profit 7,557.34

Insert Content Export

FIGURE 12.23 Sample general purpose financial statements (continued)

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 571
 FIGURE 12.23 (continued)

Balance Sheet
L & E bicycles
As at 30 June 2015

Assets 30 Jun 2015

Bank

Australia Bank 19,100.00

Total Bank 19,100.00

Current Assets

Accounts Receivables 18,870.00

Inventory 25,418.37

Total Current Assets 44,288.37

Total Assets 63,388.37

Liabilities

Current Liabilities

Accounts Payable 58,900.00

GST (1,902.73)

Total Current Liabilities 56,997.27

Total Liabilities 56,997.27

Net Assets 6,391.10

Equity
Current Year Earnings 6,391.10

Total Equity 6,391.10

Insert Content Export

Source: © Xero Limited.

The main risk attached to producing financial reports is reporting incorrect data. Oversight by senior
accounting staff and internal audit and regular checks for compliance with accounting standards and
policies will act to reduce this risk.

572 PART 3 Systems in action

Produce reports — DFD
The level 1 DFD in figure 12.24 contains a lower level of details about the final process represented in
the level 0 logical DFD in figure 12.9. This process takes place after the general ledger accounts have
been adjusted in the preceding process.

3.0
Record
general ledger
adjustments

(44)

4.1
(45) Produce
management
(46)
reports

Various (47)
departments

(48)

General ledger

4.2 (49)
Produce
financial
statements

(50)

External
users

FIGURE 12.24 General ledger and financial reporting cycle level 1 logical diagram — process 4.0
Produce reports

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 573
Operational Request ad hoc Receives
departments reports management report

Creates Generates financial

Computer
management report reports

Receives financial
External users
report

Receives financial
Senior management
report

FIGURE 12.25 General ledger and financial reporting cycle process map — process 4.0 Produce reports

Summary description of activities in producing reports

Table 12.5 summarises the activities, risks and controls when producing reports, as depicted in the
level 1 in DFD in figure 12.24 and the process map in figure 12.25. Table 12.1 explains the logical
data flows depicted in the logical DFD in figure 12.24 and the process map in figure 12.25. Exploring
the diagram in conjunction with the material contained in the tables will assist in improving your
understanding of the process depicted.

574 PART 3 Systems in action

 TABLE 12.5 Activities in producing reports

Usually Typical risks

Activity # Activity conducted by Activity description encountered Common controls

4.1 Produce Accounting Reports are created based Incorrect report Limiting report
management staff/ on a report specification parameters/incorrect generation functionality
reports department template that outlines the data reported to appropriately trained
staff/ column headings, totals staff (see example in
computer required and layout for the figure 12.26)
required report. This report
Requiring independent
template is then populated
authorisation for any
with the transaction data
new reports
that fits the requested report
parameters.
Unauthorised Secure privacy settings on
distribution of electronic reports limiting
financial data (unlike ability to print/redistribute
the general purpose reported data
financial statements
Secure document
these reports are not
management for reports
intended for use or
containing sensitive data
distribution outside the
organisation) Security profiles allowing
read-only access to
financial data maintained at
an individual staff member
level

4.2 Produce Accounting General purpose financial Incorrect data reported Oversight by senior
financial staff/ statements are produced accounting staff and
statements computer at predetermined intervals internal audit
and are constructed in Regular checks for
accordance with relevant compliance with accounting
accounting standards. standards and policies
Accounting standards are
used to create the business
rules and specifications
underlying the financial data
and report parameters.

Physical DFD — prepare budgets

The physical DFD depicted in figure 12.27 shows an example of how a budget may be prepared. The
physical diagram draws the process from a different perspective to the logical DFD of this process con-
tained in figure 12.10, as it shows who is involved in the activities of the process, rather than when those
activities occur. This process of preparing budgets involves the budget officer and the budget manager,
who interact with a central computer and with each other, and with various operational departments.
Outputs from this process are recorded in the general ledger data store for use in monitoring and man-
aging future performance.
Details of the physical data flows in figure 12.27 are contained in table 12.6. As this diagram is drawn
from a different perspective to the logical DFD, it contains far more detail about the interactions between
each of the entities involved in preparing the budget.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 575
 L & E Bicycles Alison Parkes

Dashboard Accounts Payroll Reports Contacts Settings

General Settings › Users ›

Invite a User

What’s this?

Enter their details

First Name Last Name Email

Junior Staff

Access to the accounts

Choose the user’s level of access to this organisation’s accounts:

Bank reconciliation ? Invoices Edit settings ? View reports ? Publish reports ? Lock dates ?

None

Read Only Read Only Read Only

Invoice Only Draft only

Standard Cash Coding No Reports

Adviser

Manage Users Allow this user to add and remove users and change permissions

Payroll Admin Allow this user full payroll access, including preparing & posting pay runs and payroll reporting

Contact Bank Account Admin Allow this user to add and edit bank account details held for customers and suppliers

Continue Cancel

FIGURE 12.26 Internal control — limiting report generation functionality

Source: © Xero Limited.

Systems flowchart — prepare budgets

The DFD in figure 12.27 shows an example of how a budget may be prepared; the logical DFD in
figure 12.10 shows that same process from a logical perspective. The flowchart in figure 12.28 and the
process map in figure 12.11 both show that same process from other perspectives. The systems flow-
chart is the most detailed picture of the process, and includes both logical and physical perspectives.
The detail contained in the systems flowchart is useful when considering process redesign and when
analysing the control environment of the process depicted. Details of the flows shown in the flowchart in
figure 12.28 are documented in table 12.6.

576 PART 3 Systems in action

 1.0 (1)
Budget officer (4)
(7)

(10)

General ledger

(12) (8)
(14) (2)
2.0
Computer (13)
(6)

(11)

(15)
3.0
Budget
manager
(9)

(5)

(3)
Various
departments

FIGURE 12.27 Physical DFD — prepare budgets

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 577
 Budget manager Budget officer Computer

Start Create budget Various

Request budget (1) (3)
proforma departments
proforma
Various
departments

(5)

Budget (4) (2)

Budget estimates proforma

General
Check and (6) Approved budget
ledger
approve budget estimates
estimates

(8)

Updates
Approved (7) general ledger
budgets accounts
Approved budget
estimates
( 13 )

Finalised
( 10 ) Creates and
budget report
distributes
finalised budget
reports (9)
Various
departments

Various (1
1)
departments
Budget
confirmation Updates
( 12 )
general ledger

Final budget
( 14 )
details

Budget
finalised (15)

FIGURE 12.28 Systems flowchart — prepare budgets

578 PART 3 Systems in action

TABLE 12.6 Description of data flows in physical DFD and flowchart — prepare budgets

Flow # Data source Data destination Explanation of the physical data flows

1 Budget officer Computer The budget officer requests the computer to create a proforma
budget worksheet. The process documented assumes budget
preparation is based on the previous year’s results.

2 General ledger Computer The computer extracts historic general ledger data and creates a
data store budget proforma worksheet.

3 Computer Department The computer distributes the budget proforma worksheet to

managers the various department managers along with a request for them
to consider and update the budget estimates in light of their
expectations for the coming year.

4 Computer Budget officer The computer sends a copy of the budget proforma worksheet to
the budget officer.

5 Department Budget manager Department managers prepare and forward budget estimates for
managers the following year to the budget manager for approval.

6 Budget Budget officer The budget manager checks and approves the budgets, then
manager forwards them to the budget officer.

7 Budget officer Computer The budget officer inputs the approved budget amounts.

8 Computer General ledger The computer updates the relevant general ledger accounts with
data store the new budget estimates.

9 Computer Department The computer creates finalised budget reports and distributes
managers them to the relevant departments.

10 Computer Budget officer The computer sends a copy of the finalised budget reports to the
budget officer.

11 Department Budget officer The relevant department managers confirm their acceptance of
managers the final budget details with the budget officer.

12 Budget officer Computer Once all budget details have been confirmed, the budget officer
advises the computer that the budget has been finalised.

13 Computer General ledger The computer updates all the relevant general ledger accounts
data store with the final approved budget amounts.

14 Computer Budget officer The computer displays the final budget details to the budget
officer.

15 Computer Budget manager The computer advises the budget manager that the budget has
been finalised.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 579
12.6 Measuring general ledger and financial
reporting cycle performance
LEARNING OBJECTIVE 12.6 Justify metrics to monitor general ledger and financial reporting cycle
performance.
Process performance should be measured relative to how well the process outcomes achieve the overall
objectives of that cycle. At the start of this chapter, the objectives of the general ledger and financial
reporting cycle were described as being to effectively accumulate, summarise and transfer transactional
data, to adjust that transactional data in accordance with relevant accounting standards and policies in
an accurate and timely manner, and to ensure that all reports generated are timely, accurate, valid and
complete.
To monitor performance against these objectives a range of metrics needs to be employed, along with
some realistic targets. Examples of suitable metrics or key performance indicators (KPIs) for the general
ledger and financial reporting cycle objectives are shown in table 12.7.

TABLE 12.7 Example KPIs mapped to general ledger and financial reporting cycle objectives

Objective Example KPI

To accurately and completely determine and record • Number of budget variances reported
budget estimates • Cycle time to create budgets
• Operational manager complaints received regarding
budget errors

To validate and correctly transfer all relevant • Number of data errors detected
transactional data • Reconciled balances in subsidiary ledger control
accounts
• Number of uncleared transactions in suspense
accounts

To ensure all adjusting journal entries are accurately • Number of erroneous adjustments detected
prepared and independently authorised • Level of unadjusted balances in asset and liability
accounts
• Degree of compliance with accounting policy

To ensure all reports generated are well designed and • Number of complaints received from report users
contain relevant and accurate data • Number of data errors identified in reports

SUMMARY
12.1 Reflect on the key objectives and strategic implications of the general ledger and
financial reporting cycle.
The first part of the financial reporting and general ledger cycle involves creating budgets for the
upcoming period, then extracting transactional data generated by the operational cycles. A summarised
version of these transaction streams is transferred into the relevant general ledger accounts to create a
trial balance. Once a bank reconciliation has been successfully completed, adjusting journal entries are
prepared and input to create an adjusted trial balance. After the adjusted trial balance has been finalised,
reporting can take place.
The objective of the general ledger and financial reporting cycle is to synthesise and report data that
accurately represent business transactions and activities. To achieve this, budgets must be accurate,
and all transactions extracted and posted must be complete and accurate. The strategic implications of

580 PART 3 Systems in action

the general ledger and financial reporting cycle revolve around two main areas. The first is to do with
the need for good decision making within the organisation. Poor reports lead to poor decision making,
which can lead to eventual business failure; high-quality decision making requires good data and com-
prehensible reports. Second, the strategic implications of producing external reports are equally serious.
As external reports are widely distributed, any errors in financial reporting can lead to serious corporate
problems.
12.2 Evaluate common technologies underpinning the general ledger and financial
reporting cycle.
A range of data management tools are available to help improve the ability to transfer, analyse and report
financial data within the general ledger and financial reporting cycle, including enterprise resource plan-
ning (ERP) systems, which integrate the general ledger with the operational cycles that precede it and
facilitate stronger controls over the extraction and posting of data from the subsidiary ledgers. Access to
online banking is helpful when preparing bank reconciliations, improving the timeliness and accuracy of
this important reconciliation. Business intelligence tools can support interrogation of the underlying data
and data dictionary and the creation of reports. eXtensible Business Reporting Language (XBRL) allows
semantics, or meaning, to be embedded within strings of financial data, allowing more in-depth analysis
to be conducted by users and recipients of financial data.
12.3 Recognise general ledger and financial reporting cycle data and key general ledger
and financial reporting business decisions.
Process business decisions are made from several different perspectives during the general ledger and
financial reporting cycle. Budget-related decisions include what level to budget at, how far to break
budget amounts down to and how high (or low) to set budget targets. Decisions relating to general
journal entries would include consideration of accounting standards and accounting policies and pro­
cedures, timing differences, and the need to incorporate data from external sources such as bank statements.
In addition to these journal adjustment decisions, the reports produced by this cycle are used to inform
decision makers within the organisation. Common examples of such reports include profitability analysis
for the organisation or a division, analysis of performance for an individual or a division, analysis of
profitability potential to guide future investment decisions and cost management analysis for decision
making.
12.4 Summarise and prepare documentation synthesising the primary activities in the
general ledger and financial reporting cycle and the data produced by these activities.
Contextually, the general ledger and financial reporting cycle involves direct interaction with entities
outside the organisation that use the general purpose financial statements produced, and with the bank
to obtain details of bank account transactions. Within the organisation, the general ledger and financial
reporting cycle interacts with the production, HR management and payroll, expenditure and revenue
cycles, along with managers of operational departments, initially to create budgets and later when con-
ducting variance analysis relating to operational performance. Primary activities within the cycle include
preparing budgets, updating the general ledger accounts, recording general ledger adjustments and pro-
ducing reports.
A range of data types are accessed by activities within the general ledger and financial reporting
cycle, including those contained in the accounts payable, accounts receivable, production costs and pay-
roll costs data stores. General ledger data stores are used to provide and store budget data. The general
ledger and financial reporting cycle activities generate the journal voucher and general ledger data. The
general ledger and financial reporting data is used to support decision making within the organisation
and to create all external general purpose financial statements.
12.5 Assess risks and compose control plans pertinent to the primary activities in the
general ledger and financial reporting cycle.
Activities within the general ledger and financial reporting cycle create exposure to a range of
known risks. Risks related to preparing budgets include under- or overestimating future revenues and

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 581
expenditures, and data entry errors. Risks related to updating the general ledger include using incom-
plete or inaccurate transactional data, or inaccurately updating that data. Risks related to adjusting the
general ledger include creating erroneous journal entries, and data entry errors. When producing reports,
there are risks that incorrect parameters of report data may be selected, or that reports may be distributed
to unauthorised users.
Common controls in the general ledger and financial reporting cycle include independent author-
isation of all data inputs and regular reconciliations of key general ledger accounts.
12.6 Justify metrics to monitor general ledger and financial reporting cycle performance.
Process performance should be measured relative to the desired outcomes of the process. To monitor
process performance, a wide range of metrics needs to be employed along with some realistic targets.
Examples of suitable performance metrics for the general ledger and financial reporting cycle include
variance analysis, the number of data errors detected, evidence of reconciled balances in subsidiary
ledger control accounts, the number of uncleared transactions in suspense accounts and the level of
unadjusted balances in asset and liability accounts. Success in reporting could be measured by the degree
of compliance with accounting policies, the number of complaints received from report users and the
number of data errors identified in the reports.

KEY TERMS
Enterprise resource planning (ERP) system An integrated suite of software that records and
manages many different types of business transactions within a single integrated database. Examples
include SAP and Oracle.
Exception report A report type that is designed specifically to identify exceptions for particular
transactions. An example is a report identifying any sales orders which have been shipped but not
billed, or a report identifying all customers who have overdue accounts receivable accounts.
eXtensible Business Reporting Language (XBRL) A data standard used when generating financial
reports.
Metric A specific measure used for a particular purpose. An example of a metric is the number of bad
debts the organisation has, which could be used to monitor accounts receivable or sales performance.
Online banking An internet-based banking facility that allows organisations to manage and view their
bank accounts online and conduct transactions such as transfers from those accounts.
Reconciliation An activity where two different sets of data that purport to represent one transaction or
set of events are compared to see if they agree. A common example is a bank reconciliation, which
reconciles the organisation’s accounting records of cash inflows and outflows with the bank’s record
(i.e. a bank statement).
Status code A code on transactions that are moving through an iteration of a process indicating which
stage of the process the transaction is at. As an example, a sales transaction may be first ‘created’,
then ‘picked’, then ‘packed’, then ‘shipped’, then ‘paid’. When each of these activities has been
completed, the status of the transaction is changed to reflect the new status.

DISCUSSION QUESTIONS
12.1 Monash Ltd has always had a strategy of cost leadership, that is, to try to sell more products at a
lower price.
During the recent economic downturn, Monash Ltd has seen its customer base diminish, and has
decided to move strategically to a product differentiation strategy, that is, providing high-quality
products and extracting a price premium from the market.
(a) What are the implications of this strategy change for the financial reporting cycle?(LO1)
(b) What changes would you expect to see in the financial reporting cycle?(LO4)

582 PART 3 Systems in action

 (c) What are the implications of this strategy change in terms of the usefulness of historic
transactional data for decision making?(LO3)
12.2 Flinders Ltd has decided to devolve responsibility for creating new financial reports from the
central IT division to the operational and central finance areas.
(a) What controls would you expect to see introduced to ensure that any new reports generated
contain reliable data?(LO5)
(b) Which activities in the produce reports process would be affected? (LO2, LO4)
(c) What changes would you expect to see in these activities?(LO4)
(d) What metrics could you use to measure the success of this initiative
post-implementation?(LO6)
12.3 Griffith Ltd has just realised that it has a timeliness problem with its general ledger data. It
updates daily transactional data from subsidiary systems to the general ledger weekly; however,
general ledger reports are available on an unrestricted basis. The CFO recently realised that
some users do not know that they need to wait until after the Sunday night update to run their
month-end reports.
(a) What decisions made during the general ledger and financial reporting cycle
would potentially be affected by this data problem? (LO3, LO4)
(b) How would those decisions be affected? How would this data problem affect
the reported results of the organisation? (LO3, LO4, LO6)
(c) How would this data problem affect other processes at Griffith Ltd? (LO1, LO3, LO4, LO6)
12.4 Curtin Ltd has a reconciliation problem. The bank reconciliation officer is unable to reconcile
the cash at bank value recorded in the general ledger account with the cash at bank balance
disclosed on the bank statements. Curtin Ltd seems to have good controls; it has separated all
cash handling and recording functions from the bank reconciliation function, and it prepares a
bank reconciliation on a weekly basis.
(a) Which internal controls might be missing? (LO5)
(b) What documentation would you examine in order to investigate this problem? (LO4)
12.5 Macquarie Ltd has a new CEO who is keen on improving process efficiency. She has reviewed
the process documentation for the prepare budgets process and has asked you to remove the
requirement for operational managers to confirm their acceptance of the finalised budget
amounts, as it appears to be totally inefficient.
(a) Should you agree to remove this budget confirmation activity? Why or
why not? (LO1, LO3, LO5)
(b) If you would not agree to remove the budget confirmation activity, how
would you explain this decision to the CEO? (LO1, LO5)
(c) If you would agree to remove the budget confirmation activity, how would you justify this
change to the various department operational managers? (LO1, LO5)
(d) If you remove the budget confirmation activity, would you need to measure process
performance differently? (LO1, LO6)

SELF-TEST ACTIVITIES
12.1 The general ledger and financial reporting cycle:(LO1)
(a) creates, adjusts and reports data.
(b) summarises, adjusts and reports data.
(c) creates, summarises and adjusts data.
(d) creates, summarises, adjusts and reports data.
12.2 Preparing a budget involves estimating the level of future: (LO3)
(a) activities.
(b) revenues.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 583
 (c) expenditures.
(d) all of the above.
12.3 Adjusting entries are used to:(LO3)
(a) manipulate profit levels.
(b) reduce reported variances.
(c) improve report readability.
(d) bring raw transaction data into line with accounting standards.
12.4 Management reports are often more detailed than general purpose financial statements
because: (LO4)
(a) accounting standards prohibit reporting of details.
(b) managers need lots of data to make decisions; more data = better decisions.
(c) these reports are not available externally so data security and confidentiality are not
an issue.
(d) lots of data diversity is needed in these reports to satisfy different managers’ demands.
12.5 The general ledger and financial reporting cycle interacts internally with: (LO4)
(a) the production, expenditure, and HR management and payroll cycles.
(b) the revenue and expenditure cycles.
(c) the production, expenditure, revenue, and HR management and payroll cycles.
(d) the revenue, expenditure and production cycles.
12.6 Primary risks of the general ledger and financial reporting cycle include: (LO5)
(a) erroneous budget estimates.
(b) inappropriate journal entry adjustments.
(c) data entry errors.
(d) all of the above.
12.7 A bank reconciliation should be performed: (LO5)
(a) regularly.
(b) if there is a problem in the cash account balance.
(c) by the finance manager.
(d) if you don’t use online banking facilities.
12.8 It is not useful to base your budget on prior year results when: (LO5)
(a) operational managers want to prepare their own estimates.
(b) predictable change in the business environment will affect the coming year’s operations.
(c) unpredictable change in the business environment will affect the coming year’s
operations.
(d) you had low budget variances reported in the prior year.
12.9 Keeping detailed supporting documentation for all adjusting journal entries helps to:(LO6)
(a) pass an audit.
(b) ensure that all accounting standards have been considered.
(c) provide an audit trail to enable identification and tracking of adjustments made.
(d) prepare better management reports.
12.10 Risks encountered when extracting and validating transactional data typically include: (LO5)
(a) incomplete data.
(b) inaccurate data.
(c) neither (a) nor (b).
(d) both (a) and (b).
12.11 Variance analysis reporting is used to monitor: (LO3)
(a) whether adjusting journal entries were accurate.
(b) organisational and/or process performance.
(c) compliance with accounting standards.
(d) future activity levels.

584 PART 3 Systems in action

PROBLEMS
The case narrative below (AB Hi-Fi) will be used to complete problems 12.1–12.14. Make sure you read and
understand the activities and the case thoroughly before you commence work on the problems.

AB Hi-Fi general ledger and financial reporting cycle

AB Hi-Fi is a multi-store retail business that sells products such as DVDs, CDs, mp3 players, game con-
soles and TVs. In addition to retail stores, AB Hi-Fi also sells music, games and DVDs via its website.
AB Hi-Fi has a small central finance and accounts unit that is responsible for oversight of all accounting
matters. The finance and accounts unit consists of a full-time finance officer, a seasonal budget officer
who works full time from May to July, and a part-time accountant who works three days per week. The
narrative of the AB Hi-Fi general ledger and financial reporting cycle follows.
Process 1.0 Prepare budgets
AB Hi-Fi creates its budgets in May of each year for the upcoming fiscal year (1 July to 30 June). The
budget for AB Hi-Fi is set at store level, with each store manager responsible for contributing to the
budget process. In addition to the store budgets, which focus on expected sales revenue and associ-
ated costs, expenditure budgets are created for corporate service units such as the production division,
information technology, warehousing and human resources units.
The budget process starts on 1 May every year. On this date the computer automatically extracts the
current year’s budget and actual totals for every revenue and expenditure account code in the general
ledger data store. The computer calculates the forecast actual totals for the current year by taking the
value of the transactions for the year to date (i.e. 1 July to 30 April) and increasing this total by 17 per
cent to allow for the remainder of the year. The computer then creates a proforma budget for each of
the stores and corporate service units. The proforma budget is based on the current year budget; it
also includes the forecast actual year total and the estimated annual variance for each account. Once
the proforma budgets have been created, the computer distributes an electronic copy to the nominated
manager for each division and prints copies on the budget officer’s printer. The budget officer files the
proforma budgets in a folder named ‘pro-forma budgets 20xx–xx’.
When a manager receives their proforma budget, they open and view the data, then make any adjust-
ments they feel are necessary. Any adjustment must have an accompanying note explaining why the
adjustment was considered necessary. Typical notes would include ‘I adjusted my sales revenue up by
5 per cent as this region is experiencing population growth’ or ‘The cost of raw materials is increasing
so I have increased costs overall by 2 per cent’. Once the manager has finished making adjustments,
they tick a box on the proforma to indicate their adjustments are final, then close and save the pro-
forma budget. Immediately after an adjusted proforma budget is finalised and saved, the central com-
puter prints a copy of the adjusted budget and the relevant notes on the printer in the budget officer’s
office. The budget officer compares the adjusted version to the proforma version to identify changes
made. They then read through the adjustment explanations and highlight anything that they think looks
unusual for follow-up. For store budgets, the budget officer also calculates the estimated gross profit
percentage to make sure it meets acceptable guidelines, highlighting any store budget that will not meet
the required gross profit target. The budget officer attaches the copy of the original proforma budget to
the adjusted version and the explanatory notes, and then files them in a folder called ‘adjusted budgets
awaiting approval’.
Every Friday during May and June, the budget officer and the senior management team meet to
consider the adjusted proforma budgets received during that week. During the meeting, the budget
officer records any amendments requested by senior management in a notepad. After the meeting,
the budget officer requests the computer to open the first proforma budget discussed at the meeting
and checks their notes to see if any amendments were requested. If an amendment is necessary,
the officer types the new amounts into the proforma budget. Once all the numbers look correct, the
officer ticks a box on the proforma to indicate the budget is complete, then saves and closes the
amended final budget. The computer transfers each budget amount into the relevant general ledger
revenue and expenditure accounts. The officer processes each amended proforma budget in the

(continued)

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 585
 same manner. Once all the budget amendments have been completed, the budget officer requests
a print-out of the final budgets. The computer prints two copies of each final budget on the budget
officer’s printer. The budget officer attaches one copy of the final budget to the related proforma
budget, then files them in a folder named ‘final budgets 20xx–xx’. The budget officer sends the
second copy of the final budget to the relevant manager, along with a memo explaining what has
been amended and why. If no amendments were made, the budget officer sends just the printed
copy of the final budget to the manager.

Process 2.0 Update the general ledger

Every night at 10 pm, the computer receives details of production cost totals for the preceding day
from the production cycle. The computer debits the relevant totals to the raw materials, direct labour
and manufacturing overhead general ledger accounts, and credits the total of all the production costs
to the production cost control general ledger account. Once this processing is completed, the com-
puter updates the status of the transactions held in the production data stores to ‘posted’.
After every payroll run, the computer receives details of salary and wages costs for the preceding
pay period from the payroll cycle. The computer debits the amounts to the relevant salary expense
accounts, and credits the total amount to the cash at bank general ledger account. Once this pro-
cessing is completed, the computer updates the status of the transactions held in the payroll data
store to ‘posted’.
At 1 am every morning, the computer automatically extracts the details of any supplier invoices
approved for payment during the preceding day from the accounts payable data store and then
calculates a batch total. The batch total of the invoices is credited to the accounts payable general
ledger account, and offsetting debits are created in each of the relevant general ledger expenditure
accounts. Once this processing is completed, the computer updates the status of the transactions
held in the accounts payable data store to ‘posted’. Immediately after processing the invoices,
the computer extracts the total of payments made during the day from the accounts payable data
store and calculates a batch total. The batch total of payments made is credited to the cash at
bank general ledger account and debited to the accounts payable general ledger account, then the
original cash payment transaction status is updated to ‘posted’. Once all accounts payable pro-
cessing has been completed, the computer runs a balance check to ensure that the balance of the
accounts payable general ledger account agrees with the total of all the supplier balances owing in
the accounts payable data store. If these totals do not agree, an email is sent to the IT help desk
requesting follow-up.
At 5 am every morning, the computer automatically extracts the details of any customer invoices
raised during the preceding day from the accounts receivable data store, and then calculates a batch
total. The batch total of the invoices is debited to the accounts receivable general ledger account,
and offsetting credits are posted to each of the relevant general ledger revenue accounts. Once this
processing is completed, the computer updates the status of the original transactions held in the
accounts receivable data store to ‘posted’. Immediately after this process has been completed, the
computer runs a balance check to ensure that the totals contained in the accounts receivable general
ledger account agree with the total of all the customer balances owing contained in the accounts
receivable data store. If these totals do not agree an email is sent to the IT help desk requesting
follow-up.
At 1 pm every day an electronic payment notification is received from the bank which contains details
of all credit card payments received from online orders for the previous day. The computer calculates
the total transferred, then credits this total to the online sales general ledger account and debits the
same total to the cash at bank general ledger account.
Throughout the day, whenever a cash receipts batch is successfully processed the computer extracts
the batch total details, then credits this total to the accounts receivable general ledger account. The
total is debited to the cash at bank general ledger account and the status of the cash receipts batch is
updated to ‘posted’.

Process 3.0 Record general ledger adjustments

Throughout the month, the finance officer receives requests from stores and divisions for general journal
entries to correct and adjust financial records. A typical example would be where a transaction has been

586 PART 3 Systems in action

incorrectly coded and it is necessary to reverse the original transaction and post a correct transaction
to ensure the financial reports are accurate. Another common request would relate to stock or labour
transfers between stores, where a transfer price has been agreed upon. The finance officer checks the
general ledger account numbers on the journal request for accuracy, and then enters the journal into
the computer. The computer checks that the journal transaction balances (i.e. debits = credits), then
updates the relevant general ledger accounts.
Every Monday, the finance officer manually prepares a bank reconciliation for the main trading
account of AB Hi-Fi. Once the bank reconciliation is balanced, the finance officer prepares journal
entries to record any bank-initiated transactions such as bank fees or periodical payments. The
finance officer inputs the amounts from each journal entry as a separate batch into the computer.
The computer checks that the journal transaction balances and then updates the relevant general
ledger accounts. After all the journal transactions have been input successfully, the finance officer
checks that the balance displayed for the cash at bank general ledger account agrees with the
balance calculated during the bank reconciliation. Once the finance officer is sure that the cash
at bank balance in the general ledger is correct, they sign and date the bank reconciliation docu-
mentation, attach the related journal entries and then file the paperwork in date order in a file called
‘bank reconciliations’.
On the fourth day of every month, the month-end processing begins. Note that accruals for standard
items such as accounts receivable and payable are automatically created during routine processing.
At 7 am, the computer automatically initiates processing of preset depreciation charges by debiting
depreciation expenses accounts and crediting the relevant asset accounts. The computer also adjusts
the doubtful debts provision based on a predefined algorithm and makes any necessary reversals for
previous months’ journal entries.
On the next working day, the finance officer manually adjusts the general ledger balances to
record any payroll liabilities. The finance officer calculates the value of any salary and wages owing,
then writes up an adjusting journal to debit the relevant salary and wage expense general ledger
accounts and credit the salary and wages payable general ledger account. The finance officer
inputs the journal entry into the computer and ticks a box on the journal entry screen to indicate
that the journal must be automatically reversed during the next accounting period. The computer
checks that the journal balances, and then posts the transactions to the nominated general ledger
accounts.
Process 4.0 Produce reports
AB Hi-Fi has a suite of standard month-end reports that are automatically generated and distributed.
These reports include a profit and loss account and a budget vs actual variance report for each store
and corporate service unit. On the seventh day of every month, the computer extracts data from all
the relevant general ledger accounts, generates the standard reports and prints them on a central
printer. A staff member from the IT help desk collects the reports, writes the relevant manager’s
name on the back of each one, and then puts them into unlocked mailboxes for distribution to the
managers.
During the month, requests are often received from managers for additional reports. These requests
are sent to the finance officer, who decides whether a new report needs to be created, or if there is
an existing report that would present the data required. The finance officer always checks the sup-
plementary report folder to see whether there is a previous report that might suit, but most requests
need a new report. For new reports, the finance officer sends the report request to the IT help desk
for action. Once the report has been created, a copy is sent to the requesting manager, and also to
the finance officer. The finance officer files copies of all new reports in a folder called ‘supplemen-
tary reports’.
AB Hi-Fi produces quarterly financial statements that are distributed to senior management and the
board of directors. After board acceptance and audit sign-off, these financial statements form the basis
of the company’s tax returns and the corporate reports required to be lodged with ASIC. On the tenth
day of every new quarter (i.e. October, January, April, July) the computer extracts data from all the rel-
evant general ledger accounts, generates the financial statements and prints them on a central printer. A
staff member from the IT help desk collects the reports, addresses them, and puts them into unlocked
mailboxes for distribution to senior management. Copies of the reports for board members are posted
to their supplied address.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 587
12.1 Prepare a context diagram for the general ledger and financial reporting cycle at
AB Hi-Fi.(LO4)
12.2 Prepare a level 0 logical DFD for the general ledger and financial reporting cycle at
AB Hi-Fi.(LO4)
12.3 Prepare a level 1 logical DFD for:(LO4)
(a) process 1.0 at AB Hi-Fi.
(b) process 2.0 at AB Hi-Fi.
(c) process 3.0 at AB Hi-Fi.
(d) process 4.0 at AB Hi-Fi.
12.4 Prepare a process map for:(LO4)
(a) process 1.0 at AB Hi-Fi.
(b) process 2.0 at AB Hi-Fi.
(c) process 3.0 at AB Hi-Fi.
(d) process 4.0 at AB Hi-Fi.
12.5 Prepare a physical DFD for:(LO4)
(a) process 1.0 at AB Hi-Fi.
(b) process 2.0 at AB Hi-Fi.
(c) process 3.0 at AB Hi-Fi.
(d) process 4.0 at AB Hi-Fi.
12.6 Prepare a systems flowchart for:(LO4)
(a) process 1.0 at AB Hi-Fi.
(b) process 2.0 at AB Hi-Fi.
(c) process 3.0 at AB Hi-Fi.
(d) process 4.0 at AB Hi-Fi.
12.7 Table 12.2 identifies two risks typically encountered when preparing a budget.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the prepare budgets process at AB
Hi-Fi.
(b) Determine how many of the common controls described in table 12.2 are present in the
prepare budgets process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
prepare budgets process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the prepare
budgets process at AB Hi-Fi in order to reduce the level of risk.
12.8 Table 12.3 identifies three risks typically encountered when updating the general ledger.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the update the general ledger
process at AB Hi-Fi.
(b) Determine how many of the common controls described in table 12.3 are present in the
update the general ledger process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you think the
update the general ledger process is, and how comprehensive the current internal controls are.
(d) Prepare a recommendation describing any changes you would like to make to the update the
general ledger process at AB Hi-Fi in order to reduce the level of risk.
12.9 Table 12.4 identifies two risks typically encountered when adjusting the general ledger.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the adjust the general ledger
process at AB Hi-Fi.
(b) Determine how many of the common controls described in table 12.4 are present in the
adjust the general ledger process at AB Hi-Fi.

588 PART 3 Systems in action

 (c) Prepare a short report suitable for senior management to explain how risky you think the
adjust the general ledger process is, and how comprehensive the current internal controls
are.
(d) Prepare a recommendation describing any changes you would like to make to the adjust the
general ledger process at AB Hi-Fi in order to reduce the level of risk.
12.10 Table 12.5 identifies three risks typically encountered when producing reports.(LO5)
Required
(a) Analyse the degree of exposure to each of these risks for the produce reports process at
AB Hi-Fi.
(b) Determine how many of the common controls described in table 12.5 are present in the
produce reports process at AB Hi-Fi.
(c) Prepare a short report suitable for senior management to explain how risky you
think the produce reports process is, and how comprehensive the current internal
controls are.
(d) Prepare a recommendation describing any changes you would like to make to the produce
reports process at AB Hi-Fi in order to reduce the level of risk.
12.11 AB Hi-Fi has adopted a price differentiation strategy. Its overall plan is to gain market share by
improving product quality. How well does its current prepare budgets process align with this
business strategy? Are there any opportunities to improve the degree of alignment between the
prepare budgets process and the business strategy? Explain what you would change and how
this would improve the strategic alignment. (LO1)
12.12 (a) Identify and describe the technologies that AB Hi-Fi uses in its general ledger and financial
reporting cycle activities.(LO2)
(b) For each of those technologies you identified in part (a), how well does AB Hi-Fi use the
technology? Could you suggest a way to improve the business benefit obtained by use of
any of these technologies?(LO2)
(c) Are there other suitable technologies available that AB Hi-Fi could be using for the general
ledger and financial reporting cycle activities? What business benefit would these additional
technologies provide?(LO2)
12.13 During process 3.0 Record general ledger adjustments at AB Hi-Fi, a finance officer actions
requests from stores and divisions for general ledger adjustments related to incorrect codings
and inter-store transfers. Take a moment to review this section of the narrative before you
complete the following questions.(LO3)
Required
(a)What data does the finance officer draw on when making the decision?
(b)Where does the data you identified in part (a) come from?
(c)Are these data reliable; that is, is there any possibility that there could be errors in the data?
(d)Are these data sufficient to make the decision, or can you identify additional data that the
officer should consider when making the decision?
(e) What would be the consequences of an incorrect decision?
12.14 Explain how you would measure performance of the general ledger and financial reporting
cycle at AB Hi-Fi, specifically:(LO6)
(a) What metrics would you use to measure performance?
(b) For each metric, explain where you would obtain the data required.
(c) For each metric, explain why it is a good metric to help measure how well the general
ledger and financial reporting cycle is meeting its objectives.
The case narratives below for Yayy Online will be used to complete problems 12.15–12.34. Make sure
you read and understand the activities and the case thoroughly before you commence work on the
problems.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 589
 Narrative of Yayy Online
Yayy is a specialised online store that sells only one product each day. In addition to selling only one
product each day, Yayy offers the product of the day for sale until their stock runs out or until the end of
the day, whichever comes first. Typical Yayy products are inexpensive (generally between $15 and $50),
and are mostly technology-related gadgets.
Yayy Online — prepare budgets
Yayy creates its annual budget in April each year for the upcoming fiscal year (1 July to 30 June). The
budget for Yayy is set up centrally and at a fairly high level of granularity. Revenues and expenditures
are identified as relating to either a product and its associated logistics, or central administration and
management. On 1 April, the budget process starts. On this date, the finance officer contacts the
sales manager, the purchasing manager, the production manager and the office manager to remind
them that they need to prepare budget estimates for all revenue and expenditure items under their
control. These managers each prepare an Excel spreadsheet containing their budget estimates and
forward it to the budget officer. The budget officer consolidates the four spreadsheets into a single
budget spreadsheet, then saves it locally on their PC and sends a copy to the four managers and to
the accountant.
In the last week of May the budget officer meets with the four senior managers and the accountant
to finalise the budget. During the meeting, the budget officer has a copy of the budget spreadsheet
open on a laptop which is projected onto a large screen in the boardroom where they are meeting.
The budget officer makes any changes requested, senior management view the revised spreadsheet
and confirm that these changes are correct. At the end of the meeting, the budget officer copies the
final budget spreadsheet from the laptop onto a USB key belonging to each of the senior manage-
ment team. After the meeting, the budget officer transfers the budget spreadsheet back onto their
PC, saves a copy locally and prints a copy. The budget officer inputs the budget amounts for the
relevant general ledger revenue and expenditure accounts into the accounting system. The budget
officer notes the date that the budget amounts were input on the printed budget spreadsheet, then
files it.

12.15 Prepare a context diagram for preparing budgets at Yayy Online.(LO4)

12.16 Prepare a level 0 logical DFD for preparing budgets at Yayy Online.(LO4)
12.17 Prepare a process map for preparing budgets at Yayy Online.(LO4)
12.18 Prepare a physical DFD for preparing budgets at Yayy Online.(LO4)
12.19 Prepare a systems flowchart for preparing budgets at Yayy Online.(LO4)

Yayy Online — update the general ledger

At 10 pm every day, an electronic payment notification is received from the bank that contains details of
all credit card payments received online the previous day. The computer calculates the total of the pay-
ments received, then credits this amount to the sales general ledger account and debits the same total
to the cash at bank general ledger account.
Every Monday morning, the computer extracts details of component and direct labour costs for the
previous week from the inventory data store. The computer debits these costs to the relevant general
ledger accounts and credits the total of all the production costs to the production cost control general
ledger account. The computer also extracts the details of any supplier invoices paid during the preceding
week and credits the total paid to the cash at bank general ledger account; offsetting debits are created
in each of the relevant expenditure accounts. After every payroll run, the computer receives details of
salary and wages costs for the preceding pay period from the payroll cycle. The computer debits the
amounts to the relevant salary expense accounts and credits the total amount to the cash at bank
general ledger account.

12.20 Prepare a context diagram for updating the general ledger at Yayy Online. (LO4)
12.21 Prepare a level 0 logical DFD for updating the general ledger at Yayy Online. (LO4)

590 PART 3 Systems in action

12.22 Prepare a process map for updating the general ledger at Yayy Online. (LO4)
12.23 Prepare a physical DFD for updating the general ledger at Yayy Online. (LO4)
12.24 Prepare a systems flowchart for updating the general ledger at Yayy Online. (LO4)

Yayy Online — record general ledger adjustments

On the last Friday of every month, the finance officer logs onto the online banking website and down-
loads a transaction statement. The finance officer uses this transaction statement and the finance
system data to reconcile the bank account of Yayy Online. After completing the bank reconciliation,
the finance officer handwrites any journal entries related to the bank reconciliation, and then gives a
copy of the reconciliation and proposed journal entries to the accountant who checks and approves
them.
Once the accountant has approved the reconciliation and journal entries, the finance officer inputs
the amounts from each journal entry into the computer. The computer checks that each journal trans-
action balances, and then updates the relevant general ledger accounts. Once the finance officer is
sure that the cash at bank balance in the general ledger matches the amount on the bank reconcili-
ation form, they sign and date the bank reconciliation form, attach the related journal entries and file
the paperwork.
On the second Tuesday of every month, month-end processing begins. At 11 pm, the computer auto-
matically processes depreciation charges by debiting depreciation expenses accounts and crediting
the relevant asset accounts. The computer also makes any necessary reversals relating to the previous
months’ journal entries. On the next working day, the finance officer adjusts the general ledger balances
to record salary and wage liabilities. The finance officer calculates the value of any salary and wages
owing, then writes up an adjusting journal which is sent to the accountant for authorisation. Once the
journal entries have been authorised, the finance officer inputs the debits and credits into the computer
and ticks a box to indicate that the journal must be automatically reversed during the next accounting
period. The computer checks that the journal balances, and then posts the transactions to the nomi-
nated general ledger accounts.

12.25 Prepare a context diagram for recording general ledger adjustments at Yayy Online.(LO4)
12.26 Prepare a level 0 logical DFD for recording general ledger adjustments at Yayy
Online.(LO4)
12.27 Prepare a process map for recording general ledger adjustments at Yayy Online.(LO4)
12.28 Prepare a physical DFD for recording general ledger adjustments at Yayy Online.(LO4)
12.29 Prepare a systems flowchart for recording general ledger adjustments at Yayy
Online.(LO4)

Yayy Online — produce reports

Yayy Online has a monthly board meeting where reports are presented and discussed. One week before
the scheduled board meeting, the finance officer generates and distributes the standard reports to the
board members via email as PDF attachments. Standard reports include a profit and loss account, a
year-to-date budget vs actual variance report, and a production costs summary for the previous month.
Once the board has discussed and accepted the reports, this financial data forms the basis of the
company’s tax returns and external corporate reports. Senior managers sometimes request additional
reports. These requests are emailed to the finance officer who devises and creates a new report tem-
plate in the finance system. Once the report has been created and tested by the finance officer, a notifi-
cation is emailed to the requesting manager, along with instructions for running the report. Once a year,
the finance officer generates the annual financial statements and distributes them to board members
via email. After the annual financial statements have been approved by the board, the finance officer is
advised verbally. The finance officer notifies the accountant via email that the year-end processing has
been completed.

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 591
12.30 Prepare a context diagram for producing reports at Yayy Online.(LO4)
12.31 Prepare a level 0 logical DFD for producing reports at Yayy Online.(LO4)
12.32 Prepare a process map for producing reports at Yayy Online.(LO4)
12.33 Prepare a physical DFD for producing reports at Yayy Online.(LO4)
12.34 Prepare a systems flowchart for producing reports at Yayy Online.(LO4)

The case narratives below for Jays Outdoors will be used to complete problems 12.35–12.54. Make sure
you read and understand the activities and the case thoroughly before you commence work on the problems.

Jays Outdoors general ledger and financial reporting cycle

Jays Outdoors is a retail business selling outdoor entertainment goods such as tents, sleeping bags,
camping furniture etc. They are a family owned and run corporation. The accounting division is led by
the Chief Financial Officer (CFO) who is supported by two full-time staff. A senior accounts officer deals
with supplier invoices, accounts payable and budgets. An accounts officer is responsible for customer
invoices and accounts receivable. In addition to overseeing all transaction processing, the accounts div-
ision is responsible for preparing any operational reports requested by operational managers as well as
producing monthly financial reports for the board and CEO.
Process 1.0 Prepare budgets
Jays uses a zero-based budgeting approach to prepare their annual budget. On the last day of April
in each year the CFO distributes a preformatted Excel spreadsheet and requests all operational man-
agers to prepare justified estimates of the upcoming year’s revenue and expenditure. Managers are
required to submit these estimates via email by the second Friday in May. On the third Wednesday
in May the senior accounts officer opens the spreadsheets and consolidates the data into a single
spreadsheet to form the draft budget. The accounts officer emails this draft budget to the CFO, who
reviews it and makes any changes she thinks necessary. The draft budget is taken to the May board
meeting (held on the fourth Friday) for approval, along with notes to the budget and supporting papers
which have been prepared by the CFO. Once the board has reviewed and approved the budget, the
CFO sends the final approved budget to the accounts officer who inputs the budget totals into the
accounting system.

12.35 Prepare a context diagram for preparing budgets at Jays Outdoors.(LO4)

12.36 Prepare a level 0 logical DFD for preparing budgets at Jays Outdoors.(LO4)
12.37 Prepare a process map for preparing budgets at Jays Outdoors.(LO4)
12.38 Prepare a physical DFD for preparing budgets at Jays Outdoors.(LO4)
12.39 Prepare a systems flowchart for preparing budgets at Jays Outdoors.(LO4)

Process 2.0 Update the general ledger

All transactions related to business activities in the revenue and expenditure cycles are automatically
and immediately updated into the general ledger when they are input into the accounting system. Every
night the accounting system runs a set of diagnostic routines which check that ledger balances are
correct and all transactions have been successfully recorded. Once these automated routines are suc-
cessfully completed, a report that either lists any errors detected or notifies that no errors were detected
is sent via email to the CFO.

12.40 Prepare a context diagram for updating the general ledger at Jays Outdoors.(LO4)
12.41 Prepare a level 0 logical DFD for updating the general ledger at Jays Outdoors.(LO4)
12.42 Prepare a process map for updating the general ledger at Jays Outdoors.(LO4)
12.43 Prepare a physical DFD for updating the general ledger at Jays Outdoors.(LO4)
12.44 Prepare a systems flowchart for updating the general ledger at Jays Outdoors.(LO4)

592 PART 3 Systems in action

 Process 3.0 Record general ledger adjustments
On the first Monday of every month the senior accounts officer prints out a trial balance and then writes
up any necessary general journal entries using a preformatted Word file. The trial balance and a printed
copy of the journal entries are given to the CFO who checks and approves the journals. Once the
journal entries have been approved, the CFO gives the document to the accounts officer who inputs the
journal entries into the accounting system, then initials and files the journal entry documentation. Once
the accounts officer has verbally notified the senior accounts officer that the journal entries have been
input, the senior accounts officer prints a trial balance and checks that the account totals are correct.
After the senior accounts officer has checked the account balances, they advise the CFO via email that
month-end processing has been completed.

12.45 Prepare a context diagram for recording general ledger adjustments at Jays
Outdoors.(LO4)
12.46 Prepare a level 0 logical DFD for recording general ledger adjustments at
Jays Outdoors. (LO4)
12.47 Prepare a process map for recording general ledger adjustments at Jays Outdoors. (LO4)
12.48 Prepare a physical DFD for recording general ledger adjustments at Jays Outdoors. (LO4)
12.49 Prepare a systems flowchart for recording general ledger adjustments at Jays
Outdoors.(LO4)

Process 4.0 Produce reports

After the month-end processing is complete, the CFO prepares a set of financial reports for the
board meeting, which Is held on the fourth Friday of every month. The CFO prints out the necessary
reports (Statement of Financial Position, Statement of Financial Performance and Statement of Cash
Flows) and uses them to prepare an in-depth analysis of the financial performance. After finalising
the financial analysis report, the set of financial reports and the financial analysis are emailed in .pdf
format to the accounts officer. The accounts officer downloads a preformatted board documentation
cover sheet, and then combines the separate .pdf files into a single document. After checking the
combined .pdf file, the accounts officer emails a copy to the board members, the CFO and the senior
accounts officer.

12.50 Prepare a context diagram for producing reports at Jays Outdoors.(LO4)

12.51 Prepare a level 0 logical DFD for producing reports at Jays Outdoors.(LO4)
12.52 Prepare a process map for producing reports at Jays Outdoors.(LO4)
12.53 Prepare a physical DFD for producing reports at Jays Outdoors.(LO4)
12.54 Prepare a systems flowchart for producing reports at Jays Outdoors.(LO4)

FURTHER READING
Collier, PC 2012, Accounting for managers: interpreting accounting information for decision-making,
4th edn, John Wiley & Sons, Inc., Chichester, UK.
Lee, YW 2006, Journey to data quality, MIT Press, Cambridge, MA.

SELF-TEST ANSWERS
12.1 d, 12.2 d, 12.3 d, 12.4 c, 12.5 c, 12.6 d, 12.7 a, 12.8 c, 12.9 c, 12.10 d, 12.11 b

CHAPTER 12 Transaction cycle — the general ledger and financial reporting cycle 593
ACKNOWLEDGEMENTS
Figures 12.2, 12.12, 12.16, 12.18, 12.21, 12.22, 12.23, 12.26: Screen captures from Xero used with
permission. © Xero Limited and affiliates, 2015. Xero® and the Xero logo are registered trademark
of Xero Limited. Any data displayed in these images is fictitious, and any similarities with any
actual data, individual, or entity is purely coincidental.
Photo: © jsmith / iStockphoto.

594 PART 3 Systems in action

PART 4
Systems issues
The issues considered in this part of the text are the macro type issues that apply across the
organisation and its collection of business processes. These include auditing and ethics. In
this final section, with the knowledge you have acquired about systems concepts and process
examples, you are able to take a step back and place the operation of the processes in the
broader context of the organisation. Issues that emerge as part of doing this include questions
about how the organisation can manage change within its business process. The reality is that
the environment and the needs of the organisation will change over time, necessitating systems
development. In addition, issues of how the technology is used and the risk of inappropriate use
of technology emerge, raising ethical considerations in the operation of our processes. The role
of monitoring process operation also becomes important, with internal audit filling this capacity.

13 Auditing and governance of accounting information systems 596

14 Ethics and cybercrime 633

CHAPTER 13

Auditing and governance

of accounting
information systems
LEA RN IN G OBJE CTIVE S

After studying this chapter, you should be able to:

13.1 appraise the importance of the audit function to good corporate governance
13.2 summarise the role of internal audit
13.3 explain the function of external audit
13.4 summarise the role of the audit committee in evaluating corporate governance
13.5 critique the influences on the auditor
13.6 explain the importance of the financial audit
13.7 evaluate the functions of an IS audit.
Introduction
This chapter provides an overview of what audit means, the importance of audits and the types of audits
that may be undertaken in organisations. The focus of this chapter is to clarify how audit relates to cor­
porate governance. The discussion will outline the role of internal and external auditors, the function of
the audit committee and the influences on auditors. This will help you understand the reasons for the
different types of audits and how they can help organisations achieve their business objectives.
The most common type of audit is the financial statement audit. The financial statement audit provides
an objective opinion on an organisation’s financial statements. The purpose of the financial statement
audit is for users to be able to ascertain the credibility and reliability of the financial statements of an
organisation. The definition of an audit as outlined in the report by the Committee on Basic Audit Con­
cepts of the American Accounting Association is:
A systematic process of objectively obtaining and evaluating evidence regarding assertions about econ­
omic actions and events to ascertain the degree of correspondence between those assertions and estab­
lished criteria and communicating those results to interested users.1
The audit standard ASA 200 Overall Objectives of the Independent Auditor and the Conduct of an
Audit in Accordance with Australian Auditing Standards states that the purpose of an audit is:
to enhance the degree of confidence of intended users in the financial report. This is achieved by the
expression of an opinion by the auditor on whether the financial report is prepared, in all material res­
pects, in accordance with an applicable financial reporting framework.2
Note that the auditor is providing an opinion and is not able to absolutely guarantee that the financial
report is free of misstatement. ASA 200 states that reasonable assurance is a high level of assurance and
audit professionals, in exercising professional judgement, must maintain independence and objectivity,
as well as adopting an attitude of professional scepticism in order to achieve the audit objectives.
The next section discusses the importance of the audit function and why it is important for good cor­
porate governance.

CHAPTER 13 Auditing and governance of accounting information systems 597

13.1 Importance of the audit function
LEARNING OBJECTIVE 13.1 Appraise the importance of the audit function to good corporate governance.
Corporate governance (discussed in detail in chapter 8) is the framework of rules, relationships, systems and
processes within and by which authority is exercised and controlled within corporations. It encompasses the
mechanisms by which companies, and those in control, are held to account.3 The auditing or assurance func­
tion provides the board and management with important insights into the organisational environment.
Internal control and risk management are crucial to effective corporate governance. Standards Australia
has a risk management standard, AS/NZS ISO 31000:2009, which provides organisations with guiding
principles, a generic framework and a process for management risk.4 Corporate risk extends right across
the business. Corporate risk involves all aspects of the business, including business continuity, financial
performance, intellectual property, fraud and corporate governance.
Corporate governance drives the management risk agenda. The risk management system involves two
broad areas of responsibility:
1. responsibility of the board, audit committee and management
–– define objectives, scope and priorities
–– formulate overall risk classifications
–– understand business life cycles, business processes, critical success factors
–– identify and classify risks
2. audit assurance related
–– assess probability of risk and potential consequences
–– compare and analyse risk tolerance and mitigation strategies
–– evaluate existing and new controls, costs and effectiveness of monitoring procedures
–– assess exposure, report position and recommend insurance (if necessary).
There are a number of ways professional auditors provide audit and assurance services to enhance
corporate governance. These include the internal audit function, external audits and the audit committee.

13.2 Internal auditing

LEARNING OBJECTIVE 13.2 Summarise the role of internal audit.
Internal auditing is an important function in organisations for enhancing governance processes. Corp­
orate governance is enhanced because internal auditing can improve an organisation’s operations by
­providing guidance for management decisions and more efficient business operations.
The definition of an internal audit is:
Internal auditing is an independent, objective assurance and consulting activity designed to add value
and improve an organization’s operations. It helps an organization accomplish its objectives by bringing
a systematic, disciplined approach to evaluate and improve the effectiveness of risk management, con­
trol and governance processes.5
Internal auditing is undertaken by professionals who evaluate and improve an organisation’s risk man­
agement, control and governance processes to add value to the organisation. The activities of the internal
audit function, which vary depending on the organisational characteristics (e.g. size, complexity and
industry sector), include three main areas.6
1. Activities relating to governance:
•• assessment of ethics and values, performance management and accountability, as well as the
communication of risks and controls to those responsible for governance, external and internal
auditors, and management.
2. Activities relating to risk management:
•• identification and evaluation of significant exposures to risk
•• procedures to detect fraud.

598 PART 4 Systems issues

3. Activities relating to internal control:
•• evaluation of internal control
•• examination of financial and operating information
•• review of operating activities
•• review of compliance with laws and regulations.
The internal audit function is all encompassing and involves much more than the evaluation of finan­
cial information. It includes the evaluation of controls in business processes, information systems and
systems development projects. There is a close relationship between the internal auditing function and
the organisation’s external auditors.

13.3 External auditing

LEARNING OBJECTIVE 13.3 Explain the function of external audit.
The external auditors can use the work of an internal auditor subject to guidelines outlined in the auditing
standard ASA 610 Using the Work of Internal Auditors.7 The guidelines relate to the level of objectivity
associated with the internal audit function, the level of technical competence and whether the activities
of the internal audit function have been properly planned, reviewed, supervised and documented.
An external audit is a regulatory mandate; that is, government legislation requires that organisations
undertake external audits that provide an independent opinion of the financial accounts. ASA 700
Forming an Opinion and Reporting on a Financial Report8 outlines the auditor’s responsibilities to:
1. express an opinion on the financial report
2. produce a report which states that the audit was conducted in accordance with Australian accounting
standards
3. describe the audit, including the procedures to obtain evidence
4. produce a report stating that the auditor believes that sufficient and appropriate audit evidence was
obtained to form an opinion.
The auditor gives an independent opinion that follows the directors’ opinion on the financial report.9
The auditor’s opinion states whether the financial report reports fairly in all material respects in accord­
ance with the applicable accounting framework. The auditor cannot give an absolute guarantee — the
opinion provides a reasonable level of assurance that the financial report can be relied upon. Although
the Australian auditing standards direct the auditor’s work, a high level of professional judgement is
required to determine the appropriate level of audit evidence necessary to form an opinion.
The objective of the firm is to establish and maintain a system of quality control to provide it with
reasonable assurance that:10

1. the firm and its personnel comply with AUASB [Auditing and Assurance Standards Board] stan­
dards, relevant ethical requirements, and applicable legal and regulatory requirements; and
2. reports issued by the firm or engagement partners are appropriate in the circumstances.
Audit quality may be compromised due to time constraints, management pressure and limited
resources. Non-compliance with accounting concepts and standards is unprofessional conduct. Audit
fees, particularly for large organisations, are significant. Audit firms tender to organisations for audit
and assurance work and the market is extremely competitive. Audit fees are disclosed in annual reports.
The Australian Securities and Investments Commission (ASIC) monitors audit fees, although the set­
ting of audit fees is between companies and auditors. If there are considerable changes to the audit fees
from previous years, questions may be raised about audit quality. Analysis of audit fees in Australia
from 2000 to 2011 found significant increases. The regulatory environment, through the introduction
of CLERP 9 (Corporate Law Economic Reform Program (Audit Reform and Corporate Disclosure) Act
2004) and the adoption of IFRS (International Financial Reporting Standards), as well as the increased
complexity of audit requirements, are some reasons for the increase. For example, the average audit
fee for a Big 4 client increased from $220  000 in 2000 to over $550  000 in 2011.11 ASIC has audit

CHAPTER 13 Auditing and governance of accounting information systems 599

inspection and surveillance programs that review compliance with audit quality and auditor indepen­
dence requirements to ensure that audit quality is not compromised.12
The directors of the board are accountable to shareholders. BBY, an independent Australian stock­
broking and financial services group with a global presence, was placed into administration in May 2015.
KPMG was appointed as the administrator. Preliminary findings showed that BBY may have been insol­
vent since June 2014, BBY’s financial records were not maintained in accordance with the Corporations
Act 2001 and there was possible misuse of investors’ funds.13 The consequences for directors if found in
breach of the Corporations Act include civil penalties, compensation proceedings and criminal charges.
Civil penalties could include amounts up to $200  000. Compensation payments are potentially unlimited
and could lead to the personal bankruptcy of directors. A bankrupt director is disqualified from being
a director or managing a company until the bankruptcy is discharged and an agreement reached. If dis­
honesty is found to be a factor in insolvent trading, a director may also be subject to criminal charges.
The penalties include fines of up to $220  000 and/or imprisonment. If found guilty, the director will be
disqualified from being a director or managing a company.14
In an important case, ASIC v. Healey & Ors [2011] FCA 717,15 ASIC commenced proceedings against
two directors and six non-executive directors alleging that they had breached their duty of care and
the Corporations Act. ASIC alleged that the 2007 consolidated financial statements incorrectly classi­
fied $1.5 billion in debt as non-current liabilities instead of current liabilities and failed to disclose
US$1.75 billion in guarantees. Centro Management and the auditor, PwC, had reviewed the financial
statements and the directors’ report and did not find any errors. The key question was to what extent
directors are required to turn their minds to and make a careful review of the financial statements of the
entity. This includes what the directors know or should know about the financial affairs of the company.
On 27 June 2011, Justice Middleton of the Federal Court of Australia handed down his decision. His
Honour held that the directors:
•• failed to take all reasonable steps to focus and consider for themselves the content of the financial
statements, particularly as to short-term debt and whether the guarantees should have been disclosed
•• failed to make enquiries of management, the board audit committee or other directors as to proposed
statements in the financial statements relating to the short-term debt and guarantees, and failed to have
apparent errors corrected
•• failed to request that the directors be given declarations required under s. 295A of the Act.
The penalties were relatively minor. CEO Andrew Scott was fined $30  000. The CFO (Chief Financial
Officer), Romano Nenna, was banned from running companies for two years. The six former and current
directors were not penalised.16

13.4 Audit committees

LEARNING OBJECTIVE 13.4 Summarise the role of the audit committee in evaluating corporate
governance.
The global financial crisis and corporate collapses relating to fraud, poor accounting and failure of
internal controls (e.g. Enron) have led to the increasing importance of audit committees to enhance
corporate governance. The ASX Listing Rules require certain listed entities to have audit committees.
Other companies may choose to have an audit committee. Principle 4: Safeguard Integrity in Corporate
Reporting of the Corporate Governance Principles and Recommendations states that the board of a listed
entity should have at least three members, all of whom are non-executive directors and a majority of
whom are independent. The chair of the committee must be an independent director (and not the chair
of the board). The charter of the committee, the relevant qualifications and experience of the members
of the committee and, in relation to each reporting period, the number of times the committee meets
throughout the period and the individual attendances of the members at those meetings must be disclosed.
If the company does not have an audit committee, it must explain how it independently verifies and
safeguards the integrity of its corporate reporting, including the processes for the appointment and

600 PART 4 Systems issues

removal of the external auditor and the rotation of the audit engagement partner.17 Regardless of whether
a company has an audit committee or not, it is good governance to explain to stakeholders their approach
to audit and risk.18 It is important to note that the existence of an audit committee does not change the
directors’ responsibility for the financial reports.
An audit committee is a committee of board directors and its objectives are defined in its charter. The
audit committee has three main functions:
1. to focus on issues relevant to the integrity of an organisation’s financial reporting
2. to be responsible for overseeing external audit, internal audit, risk management, internal control and
compliance
3. to liaise with the board, internal and external auditors, and management.19
Internationally, audit committees have become the mechanism for good corporate governance in both
the public and the private sectors. Audit committees provide independent assurance and advice on an
entity’s operations to the Chief Executive and Board of Directors. Audit committees also provide advice
to senior management and management committees on how to improve business performance.20
Although originally set up to oversee accounting and financial reporting, the term ‘audit committee’
is dated because the audit committee now has a mandate to cover a wide range of assurance activities,
including those not related to financial reporting. For example, the audit committee is responsible for
considering the effectiveness of the company’s internal control system, including information technology
security and control. The audit committee may also assist the board and management in a number of
areas including:
•• facilitating well-informed, efficient and effective decision making, particularly by the board
•• promoting and monitoring an ethical culture throughout the entity
•• ensuring a code of conduct is appropriately designed and implemented and compliance with the code
is monitored
•• implementing an effective system of risk oversight and management
•• implementing an effective and efficient internal control system
•• ensuring high-quality internal and external reporting (financial and non-financial)
•• obtaining an independent, effective and efficient external audit
•• promoting effective communication between the board and the internal and external auditors, and
providing timely and appropriate responses to matters arising from audits.21
The 2002 US Sarbanes–Oxley Act (SOX) similarly required the establishment of an audit com­
mittee. The significant difference is that the Australian and New Zealand approaches encourage com­
panies to follow best practice while the United States legislated for mandatory compliance. Despite the
varied approaches, the existence of an independent audit committee is recognised internationally as an
important feature of good corporate governance.

13.5 Influences on the auditor

LEARNING OBJECTIVE 13.5 Critique the influences on the auditor.
Australian auditing standards (ASAs) come under the control of the Auditing and Assurance Standards
Board (AUASB). The AUASB is an independent statutory board of the Australian government established
under section 227A of the Australian Securities and Investments Commission Act 2001 (ASIC Act). As a
statutory body, the AUASB was granted powers — by section 227B of the ASIC Act — to:
1. make auditing standards under section 336 of the Corporations Act
2. formulate auditing and assurance standards for other purposes
3. formulate guidance on auditing and assurance matters.
The AUASB issued 35 Australian auditing standards (ASAs) in 2006. The ASAs are legally enforce­
able legislative instruments under the Legislative Instruments Act 2003. The AUASB formulates auditing
standards that have a clear public interest and are of high quality. The AUASB uses International Stan­
dards on Auditing (ISAs) issued by the International Auditing and Assurance Standards Board (IAASB)

CHAPTER 13 Auditing and governance of accounting information systems 601

as the basis to develop ASAs. The IAASB is a committee of the International Federation of Accountants,
established to issue standards on auditing and reporting practices to improve the degree of uniformity of
auditing practices and related services throughout the world.22
The entire suite of ISAs was redrafted and, in some cases, substantively revised as part of the Clarity
format project initiated by the IAASB to improve the consistent application of ISAs worldwide. All of the
ASAs were correspondingly redrafted and came into force for reporting periods commencing on or after
1 January 2010. The current auditing standards are available on the AUASB website: www.auasb.gov.au/
Pronouncements/Australian-Auditing-Standards.aspx.

Benchmarks and best practice

Auditors often need other sources of guidance and may turn to best practice as a source. Best practice
may be defined as being what a skilled, experienced auditor familiar with the issue at hand would do.
It is the distilled wisdom of the auditor community and emerges from discovery of what works best
through trialling a variety of techniques and choosing the best. It responds to environmental change
more quickly than regulatory processes can. Sources of best practice include International Organization
for Standardization (ISO) standards and materials and procedures developed by the vendors and/or firms
that offer audit and assurance services.
The ISO is a non-government organisation that develops standards for specific products and services
as well as generic management system standards. ISO 9000 is a framework that provides an approach to
managing business processes to produce outputs that meet customers’ expectations. There are specific
ISO standards for many information technology-related assurance services such as:
•• ISO/IEC TR 38502:2014 Information technology — Governance of IT — Framework and model
•• ISO/IEC PDTR 38504 Information technology — Governance of IT — The structure of principles-
based standards in the governance of information technology.23
There are many ISO standards that provide guidance for IT management, including governance,
project management, service management, information security management (ISO/IEC 27000); Risk
management (ISO 31000); Records management; Systems and software engineering; Application man­
agement; Software life-cycle processes; System life-cycle processes; Architecture description; Business
continuity and disaster recovery; Energy efficiency; and Quality (ISO 9000).

13.6 Financial (statutory) audit

LEARNING OBJECTIVE 13.6 Explain the importance of the financial audit.
A financial audit is an examination of the financial report (consisting of the balance sheet, an income
statement, a statement of changes in equity, a cash flow statement, and notes comprising a summary
of significant accounting policies and other explanatory notes) to form a view independently from the
organisation as to the reliability of that information.

Requirement for a financial audit

All publicly listed companies in Australia and New Zealand are required by statute to be audited
by an appropriately qualified and certified chartered accountant. The auditor is required to state
whether or not in their opinion the accounts give a ‘true and fair view’ of the company’s activities
for the period under review and whether or not the accounts have been prepared in accordance with
generally accepted accounting principles (GAAP). The process of the auditor forming an opinion
and reporting on it is technically termed an attest service, which may be defined as an indepen­
dent accountant expressing a written opinion about the reliability of a written assertion prepared by
another party. Similar audit requirements apply to all levels of federal, state and local government
organisations, larger private companies, major charities, sporting, religious and cultural organisations,
and the like. The external accounts are prepared from summarised data in the general ledger system,

602 PART 4 Systems issues

and this in turn is derived from summarising the data generated by the transaction cycles examined in
chapters 10 to 12. All of this data has been captured, processed and stored by the accounting infor­
mation system (AIS); therefore, it follows that, if the auditors are to form an opinion that the final
accounts truly and fairly summarise the underlying transactions, then they must have confidence in
the integrity of the AIS. The way in which the auditors go about obtaining that confidence in the
integrity of the AIS is the focus of the remainder of this chapter.

Sarbanes–Oxley Act (SOX) requirements

In chapter 5 we showed how the Sarbanes–Oxley Act (SOX) has put pressure on entities to ensure that
their systems are properly documented. It was mentioned that, as United States legislation, SOX has
no legal force in Australia or New Zealand, except that compliance is required for all Australian and
New Zealand companies dual listed on a US stock exchange. In addition, it is binding on subsidiaries of
US companies such as the Ford Motor Company or Coca-Cola. SOX also exerts an indirect influence as
an exemplar of best practice.
Further, the statute has strong moral force in that the major chartered accounting firms are all US
based, so their worldwide policies and procedures incorporate requirements of SOX. As mentioned,
significant requirements (mainly in section 404 of SOX or Securities and Exchange Commission rules
made under it) include the mandatory appointment of an audit committee and an:
internal control report [that] must include: a statement of management’s responsibility for establishing
and maintaining adequate internal control over financial reporting for the company; management’s
assessment of the effectiveness of the company’s internal control over financial reporting  .  .  .  and a state­
ment that  .  .  .  [the auditor] has issued an attestation report on management’s assessment of the com­
pany’s internal control over financial reporting.24

Thus, the directors and senior management are specifically charged with the responsibility for the
financial statements and the processes (including internal control) that were used in their preparation.
This responsibility includes certifying that they believe the financial reporting process to be adequate,
and the auditors are required to issue an opinion on the management assertion, in addition to their own
opinion on the effectiveness of the company’s internal control procedures.
Other significant SOX requirements designed to ensure the independence25 of auditors include:
•• prohibiting the audit firm from carrying out non-audit services including information system
consulting, design and implementation
•• requiring audit committee approval of the audit firm performing services such as internal audit and
setting up the internal control procedures
•• requiring audit committee approval for any other non-audit services provided by the auditor and full
disclosure of fees paid for such services
•• requiring mandatory rotation of lead audit partners after five years and a time-out of five years before
becoming eligible to resume the audit
•• requiring, for a staff member of the audit firm taking up employment with the client, a time-out of
one year after leaving, otherwise the audit firm will not be considered independent.
To carry out the tasks described above, SOX created the Public Company Accounting Oversight
Board (PCAOB), a body responsible for the oversight of the auditors of public companies, with a view
to ensuring that the audit is independent and the audited accounts true and fair.26
In 2007, the PCAOB issued Auditing Standard No. 5 An Audit of Internal Control Over Financial
Reporting That Is Integrated with An Audit of Financial Statements. The standard includes the important
assertion of the nexus between internal control providing reasonable assurance of reliability (section 2)
and the explanation of the auditor’s objective in undertaking an audit (section 3).
2. Effective internal control over financial reporting provides reasonable assurance regarding the relia­
bility of financial reporting and the preparation of financial statements for external purposes.27

CHAPTER 13 Auditing and governance of accounting information systems 603

 3. The auditor’s objective in an audit of internal control over financial reporting is to express an opinion
on the effectiveness of the company’s internal control over financial reporting. Because a company’s
internal control cannot be considered effective if one or more material weaknesses exist, to form a
basis for expressing an opinion, the auditor must plan and perform the audit to obtain competent evi­
dence that is sufficient to obtain reasonable assurance about whether material weaknesses exist as of
the date specified in management’s assessment.28
Auditing Standard No. 5 also defines internal control over financial reporting as:
A process designed to provide reasonable assurance regarding the reliability of financial reporting and
the preparation of financial statements for external purposes in accordance with generally accepted
accounting principles. A company’s internal control over financial reporting includes those policies
and procedures that (1) pertain to the maintenance of records that, in reasonable detail, accurately and
fairly reflect the transactions and dispositions of the assets of the company; (2) provide reasonable
assurance that transactions are recorded as necessary to permit preparation of financial statements in
accordance with generally accepted accounting principles, and that receipts and expenditures of the
company are being made only in accordance with authorizations of management and directors of the
company; and (3) provide reasonable assurance regarding prevention or timely detection of unauthor­
ized acquisition, use, or disposition of the company’s assets that could have a material effect on the
financial statements.29
Other definitions are also outlined, including that of a control deficiency, which occurs ‘when the
design or operation of a control does not allow management or employees in the normal course of per­
forming their assigned functions, to prevent or detect misstatement on a timely basis’.
As well as financial audits, there are other types of audits, including information technology or infor­
mation systems audits, which will be covered in this chapter. The role of information technology or infor­
mation systems audits is to specifically assess IT controls including security management.30 Technology
and information systems, including accounting information systems, are enablers of business processes.
Accounting information systems contain the records and processes relating to asset and liability trans­
actions. Management therefore needs to understand the risks and threats associated with information
systems as they relate to their business objectives.

13.7 Information systems audit

LEARNING OBJECTIVE 13.7 Evaluate the functions of an IS audit.
An information systems audit (IS audit) is part of the overall audit process and is important for good
corporate governance. An information systems audit is:
The process of collecting and evaluating evidence to determine whether a computer system (infor­
mation system) safeguards assets, maintains data integrity, achieves organizational goals effectively and
consumes resources efficiently.31

ISACA — formerly the Information Systems Audit and Control Association — is a not-for-profit
association that provides four industry-leading certifications, sponsors conferences, develops and updates
COBIT and other frameworks, and provides professional standards, guidelines, tools and techniques
for IS audit and control professions.32 IS Assurance and Audit standards are documented in ITAF™,
3rd edition.33
Internal and external auditors may undertake IS audits, although the audit objective and scope will be
different from a financial audit. Information systems are a combination of manual and computer systems
and the control objectives have to relate to the whole process. They could be narrower or wider than
business processes including accounting information records. This is also important for the auditing of
B2C e-commerce transactions that require backend processes such as order fulfilment, receipt of money
and accounting for transactions.34

604 PART 4 Systems issues

 More organisations are moving to a risk-based approach to IS audit. In a risk-based IS audit, auditors
are not just relying on risk. IS auditors need also to have an understanding of internal and operational
controls as well as knowledge of the organisation. The types of risks are as follows.35
•• Inherent risk — the susceptibility of an audit area to error in a way that could be material, individually
or in combination with other errors, assuming that there were no related internal controls. For example,
the inherent risk associated with operating system security is ordinarily high, since changes to, or even
disclosure of, data or programs through operating system security weaknesses could result in false
management information or competitive disadvantage. By contrast, the inherent risk associated with
security for a stand-alone PC, when a proper analysis demonstrates it is not used for business-critical
purposes, is ordinarily low. Importantly, inherent risk for most audit areas is high because the impact
of potential errors can span many business areas and many stakeholders such as employees, suppliers
and customers.
•• Control risk — the risk that an error that could occur in an audit area and could be material,
individually or in combination with other errors, could not be prevented or detected and corrected on
a timely basis by the internal control system. For example, the control risk associated with manual
reviews of computer logs can be high because activities requiring investigation are often easily missed
owing to the volume of logged information. The control risk associated with computerised data
validation procedures is ordinarily low because the processes are consistently applied. Professionals
should consider both pervasive and detailed IS controls. Pervasive IS controls are a subset of general
controls that relate to the management and monitoring of the IS environment. Detailed IS controls
comprise general controls and those general controls not included in pervasive controls. In relation
to the COBIT framework, they are the controls over the acquisition, implementation, delivery and
support of IS systems and services.
•• Detection risk — the risk that the IS auditor’s substantive procedures will not detect an error that
could be material, individually or in combination with other errors. For example, the detection risk
associated with identifying breaches of security in an application system is ordinarily high because
logs for the whole period of the audit are not available at the time of the audit. The detection risk
associated with identifying a lack of disaster recovery plans is ordinarily low, since existence is
easily verified. The higher the assessment of inherent and control risk, the more audit evidence the
professionals should normally obtain from the performance of substantive audit procedures.
In a risk-based audit, the auditor is interested in technology-based systems where there is a high inherent
risk and in technology-based functions where there is a higher-than-acceptable residual risk. There are many
different ways of performing an IS risk assessment. The ISACA ITAF™ framework states that:
1202.1 The IS audit and assurance function shall use an appropriate risk assessment approach and
supporting methodology to develop the overall IS audit plan and determine priorities for the effective
allocation of IS audit resources.
1202.2 IS audit and assurance professionals shall identify and assess risk relevant to the area under
review, when planning individual engagements.
1202.3 IS audit and assurance professionals shall consider subject matter risk, audit risk and related
exposure to the enterprise.36
Once the risks have been evaluated, the auditor develops a plan that acts as the framework for IS
audit and assurance activities. Prior audits, reviews and findings, remedial activities and the risk assess­
ment processes of the board and management are used in the planning of the audit. The objective is to
reduce audit risk to an acceptable level and meet the audit objectives by an appropriate assessment of the
IS subject matter and related controls.37

Overview of the AIS audit

It is important that financial audits are undertaken as well as audits of critical infrastructure and appli­
cations, including those with financial statement implications. Information systems not only record busi­
ness transactions; they are the lifeblood of any business. This includes e-commerce transactional systems

CHAPTER 13 Auditing and governance of accounting information systems 605

and cloud computing. The purpose of the IS audit is to provide reviews, feedback, assurances and sug­
gestions to management with a clear assessment of the system. As AIS Focus 13.1 shows, IS auditors
require in-depth knowledge of the latest technology trends.

AIS FOCUS 13.1

Cloud computing: assessing the risks

Cloud computing is a way of expanding the capacity of information technology by using subscription-­
based services or pay-by-user services over the internet. This provides a cost-effective way of
increasing capabilities or capacity without an organisation having to invest in new infrastructure, training
or licensing new software.
Large organisations, including government agencies, are increasingly using cloud computing to
achieve the benefits of improving cost-effectiveness due to a reduction in ongoing infrastructure, oper-
ating and staff costs. On the other hand, there are risks relating to data security and sovereignty, system
performance, unauthorised access, legal and regulatory compliance, and loss of access to the system,
service or information.38
The Australian Government spends around $6 billion a year on information and communications tech-
nology (ICT). Government expenditure on ICT makes up approximately 30 per cent of the domestic
market. Therefore, adoption of cloud computing more comprehensively by government agencies is likely
to have a positive flow-on effect on the economy.39 In recent years, state and territory governments in
Australia have used cloud computing to achieve cost savings and efficiencies.
As an example, in 2014 the Office of the Auditor General in Western Australia released an Information
Systems Audit Report on the management of cloud computing in five government agencies. The audit
objective was to ascertain the extent to which agency data was being held offshore under the cloud
arrangement and whether there were appropriate controls to protect data sovereignty and security. The
agencies were the Department of Fisheries, Department of Sport and Recreation, Metropolitan Rede-
velopment Authority, Public Sector Commission and Public Transport Authority.40 The audit found that
none of the five agencies could demonstrate effective management across all of the key areas relating
to their implementation of a cloud-based service, with a consequent risk to the confidentiality, integrity
and availability of information. Common weaknesses included not assessing business risks and costs
and benefits of shifting to the cloud, inadequate contractual arrangements, and weaknesses in the IT
security and business continuity arrangements.41
The Western Australian government example shows that cloud computing can be very complex. The
main risks associated with cloud computing are loss of control, security, integrity, privacy and avail-
ability. IS auditors need to assess and mitigate the risks involved by gaining independent assurance
about the controls at the cloud computing vendor.

A historical perspective
Scott’s Plumbing Supplies is a well-established firm selling bathroom and kitchen fittings and general
plumbing supplies. It offers credit accounts to regular customers, mainly builders and plumbers. When
the business was founded, all transactions were recorded manually, using a system little different to that
first described by Pacioli.42 Sales orders were recorded using a six-copy pre-numbered form that included
a customer’s purchase order field. The order form was either signed by the customer or was authorised
by a written purchase order sent by the customer. The first order copy went to the customer, the second,
third and fourth to the warehouse, the fifth to the invoicing section and the last copy remained in the
book and was kept in the sales department. Warehouse staff picked the order authorised by the order
document and made any required changes for items out of stock. The second and third copies of the
form were sent to the customer with the goods, which were delivered using the company’s own trucks;
the customer kept the second form and signed and returned the third, which was filed in the warehouse.

606 PART 4 Systems issues

The fourth copy was sent to the invoicing section where it was matched to the fifth copy. The invoicing
section prepared a two-part invoice using data from the sales order form and a price list, using the order
number as the invoice number. The invoice top copy went to the customer and the second copy was used
to post to the sales journal, and then filed. The sales journal was subsequently used to post the item to
the customer’s account in the debtors’ ledger.
The audit process carried out to establish the reliability of the system entailed reconciling figures on
source documents (e.g. sales orders with customer invoices), then reconciling invoices with totals on
output documents (e.g. customer statements) with a view to confirming that transactions were being pro­
cessed correctly and that all transactions were included. This was referred to as following an audit trail.
Scott’s process described above left a clear audit trail. The auditor could look at any customer’s account
balance in the debtors’ ledger and trace each debit back to the individual invoice and to the signed sales
order copy. Similarly, he or she could examine any sales order and trace it forward through the system to
a charge to a customer. Sequence checks could be used to ensure that all order forms resulted in invoices
being issued or that missing documents were accounted for as either having been cancelled or still in
progress.
As technology became available, Scott’s replaced hand-written records with typed invoices and posted
the debtors’ ledger using an accounting machine but there was little change to the underlying process
or the documentation, so the audit trail remained intact. Even when Scott’s introduced its first computer
system in the mid-1970s, little changed. The handwritten sales order forms were retained; the invoicing
section wrote the customer number and the item unit price on the sales order form; and the data was
then keyed into the computer system. The computer system calculated extended prices, subtotals, taxes
and final totals, and printed the invoice. At the end of each day it also printed a listing of all invoices
prepared that day and a cumulative electronic file of invoice data. At the end of the month, this file of
invoice data was used to prepare customer statements.
Originally, Scott’s auditors treated computer systems as a ‘black box’ and attempted to audit
‘around the computer’, without finding a need to understand what the computer was doing. Scott’s
first computer system described above left a clear audit trail from sales order forms to invoices and
daily listings to customer statements, and its auditors were confident in their ability to audit ‘around
the computer’.
However, in some cases such a procedure is no longer possible and, instead, auditors must audit
‘through the computer’; that is, they audit the processes undertaken by the computer. One reason for
this change is that, with a contemporary point-of-sale system, there are often no longer any source docu­
ments to be found, so there is no independent audit trail.

Auditing today
Let’s now look at Scott’s today. The business now has several branches across the metropolitan area
and delivers using outside carriers and couriers. Sales staff ‘on the road’ may enter customer orders
into Scott’s ‘state of the art’ point-of-sale system using a laptop/tablet/smartphone, or customers may
place orders by phone or email, in which case a branch salesperson enters the orders or customers
may place their orders over the web. Regardless of the method, the system prints or electronically dis­
plays appropriate documents or outputs to devices authorising the picking and despatch of the order to
a building site, and subsequently invoices the customer. The invoicing process involves pricing using
a base price, applicable volume or special customer discount, seasonal promotion, or damaged and
obsolete stock price.
The entire process is entered and possibly edited by the salesperson; the only external evidence of the
transaction is a possible signature of an unknown person on a building site, either written on a document
or possibly recorded from a tablet into a computer system, and probably held by a third-party carrier
or courier company. Clearly, no visible audit trail exists to examine, and so in such a case it is imposs­
ible to audit around the computer. The auditor can only confirm the integrity of the computer processes
involved.

CHAPTER 13 Auditing and governance of accounting information systems 607

 So, how does an auditor go about confirming this integrity? One advantage of using computer systems
is their predictability; they do not have the same lapses in performance, nor do they make the occasional
mistakes that humans are prone to. Computers follow rules embedded in programs. If a computer cor­
rectly processes a particular transaction in a certain manner, then the auditor can confidently predict
that similar transactions will be treated in an identical manner. Therefore, the auditor needs to create a
sample of test transactions and process them through the system to ensure that they are processed cor­
rectly. This is known as auditing ‘through the computer’.
An IS audit broadly comprises five distinct phases:
•• planning the audit
•• field work
•• analysis
•• completion, review and reporting
•• monitoring and review.
We will study each of these phases in following sections, but first we will look at the tools available
to a twenty-first century auditor.

Audit tools
Audit tools fall into two categories: internal control frameworks and computer auditing tools and tech­
niques, generally known as CAATs.
Internal control frameworks
COSO and COBIT 5 are examples of control frameworks. COSO is used primarily for financial
controls and COBIT 5 is used for IT controls. Both of these frameworks are discussed in detail in
chapter 8. These frameworks are important for auditors to understand so that they can effectively
apply them when developing effective and meaningful audit procedures.43 Where organisations have
implemented either or both of these frameworks, the auditor is able to evaluate the controls in place
against the framework and it provides a reference point from which a company and its auditor can
negotiate an agreement as to what are the control objectives and which controls are appropriate
to meet those objectives. The 2013 COSO framework emphasises information technology more
explicitly than the previous version. The COSO framework sets out 17 principles, while COBIT 5
focuses on organisational goals through the use of a goals cascade model, discussed in detail in
chapter 8.
COBIT has been adopted worldwide. AIS Focus 13.2 introduces five adopters, including two major
Australian organisations, and describes some of the advantages they identified.

AIS FOCUS 13.2

COBIT and IT governance case studies

1. A large Australian government service organisation adopted COBIT to develop a customised audit
plan for an audit of mainframe capacity planning. The plan contained control objectives, audit objec-
tives and testing strategies. The plan was approved by management and used to successfully com-
plete the audit. The findings and recommendations of the audit were accepted by management and
resultant action was put in place. The organisation believes that, without COBIT, the quality of the
audit would not have been as high.
2. A major Australian university adopted COBIT and found it to be a useful tool to improve practices
and approaches to teaching tasks and responsibilities. The COBIT implementation arose in conjunc-
tion with an audit review of the university’s strategic planning, based on the balanced scorecard
methodology. Since COBIT is compliant with the balanced scorecard, it fit well with the university’s
internal strategy.

608 PART 4 Systems issues

  Together, information systems management and the internal audit function led the
adoption of COBIT as the university’s official IT governance methodology. The next strategic
step was to implement COBIT at the operational level. The drive for implementation by infor-
mation systems management greatly accelerated the implementation and acceptance rate of the
framework.
  The internal audit function observed, in relation to the adoption of COBIT, that:
• COBIT was a high resource commitment for internal audit, who invested significant staff time in
the implementation and had an ongoing commitment post-implementation.
• Some staff members initially were concerned with the term ‘performance indicators’. They thought
it caused more pressure in already pressured jobs. By renaming these ‘measures of success’, con-
cerns were alleviated.
• COBIT is a robust framework that is well thought out for diverse environments. It is best learned
and appreciated during the implementation process.
3. A large United Arab Emirates integrated and government-owned energy company implemented
COBIT as a result of its IT services having difficulty adapting to the company’s rapid growth, IT pro-
jects not being properly prioritised and IT value being increasingly questioned. A significant issue
contributing to the problems was that many IT processes were not standardised and, thus, not
repeatable, which contributed to the inefficiency of IT service delivery. The IT department faced sig-
nificant challenges in trying to meet the expectations of the business.
  The main goal of the COBIT implementation was to improve the efficiency of delivery of IT services
through improving existing processes or designing and implementing new processes. The goal has
been accomplished.
4. A leading US health insurance company adopted COBIT, in part, because it was aware that COBIT
could be leveraged to meet SOX compliance requirements. External factors caused the company
to modify its approach from a risk-based to a compliance-based focus. The approach to adopting
COBIT was termed ‘COBIT Lite’ and was to concentrate on financially significant applications. The
implementation was performed by employees who also had other responsibilities, so they focused
on reasonable and prudent controls for the environment.
  The company identified numerous benefits from implementing the COBIT framework, including
formalising and documenting controls, policies and procedures. For the most part, the required con-
trols were in place before COBIT was implemented; however, there was little documentation and
procedures were informal.
  Many areas achieved benefits from the implementation of COBIT, including being able to identify
and address minor exceptions before they became significant issues. The team also found that it
could use COBIT as a common language between various process areas and with internal auditors.
  The company listed several lessons learned, including:
• The audit/compliance perspective is different from the perspective of implementing a framework
with a focus on governance, risk management and IT control.
• It is best to build controls into a process, as it makes the controls easier to sustain and self-testing
more efficient and effective.
• Enterprise-wide change must occur in implementing a governance framework such as COBIT, and
senior-level support and communication is essential, as often the most difficult part of a program
is overcoming resistance to change.44
5. Ecopetrol S.A., a vertically integrated energy company in Colombia, used the COSO and COBIT
frameworks to consolidate strong IT governance practices to align with corporate internal con-
trol initiatives. From 2008, the IT management system incorporated the COBIT 4.1 framework
to cover the key IT control objectives to support the reliability and security of the company’s
information. Following the release of COBIT 5, a strategy was devised to migrate to COBIT 5.
The company implemented COBIT 5 by adapting the previous COBIT 4.1 operating model, ana-
lysing gaps and ensuring communication with key stakeholders. The key success factors in
adopting COBIT 5 reported by the company included information reliability, strong confidence
of IT in the internal control system, integration with organisational associated issues, ongoing
external assessment, management of culture and people, and the effective support of consulting
services.45

CHAPTER 13 Auditing and governance of accounting information systems 609

Computer assisted auditing tools
Computer assisted auditing tools (CAATs) are tools and techniques employed by auditors to extract and
analyse client data. CAATs may enhance audit effectiveness and efficiency. For example, auditors may
be able to test 100 per cent of the population instead of a sample. However, recent research has shown
that auditors do not frequently and systematically use CAATs.46
The first two techniques discussed in this section are used to directly examine the internal logic and
the other two examine it indirectly.
Testing using test data
The auditor needs to create a sample of test transactions and process them through the system to ensure
that they are processed correctly. This will ensure the auditor can have faith in the integrity of the pro­
gram and systems and in the information contained within them.
The predicted results of the test transactions should be manually calculated in advance and compared
to the test results processed by the system and any differences thoroughly investigated. Testing should
start with the simplest calculations and proceed from there, and should be made at both the individual
transaction level and the various summary total levels.
•• In a sales system, these tests may start with simple transactions such as: does quantity times unit price
equal extended price?
•• In a multi-item transaction, it could include: does sum of extended price equal subtotal?
•• The auditor should check that GST and any other applicable taxes are correctly applied: does the
subtotal plus tax equal invoice total?
Further queries might include:
•• Does sum of invoice total equal daily summary total?
•• Is the resulting daily sales journal entry arithmetically correct and posted to appropriate general ledger
codes?
•• Does the customer’s previous balance plus this invoice equal the current balance?
These test transactions should include every possible permutation of valid and invalid transactions that
could be entered into the system. This is to test that the system will provide an appropriate response to
every invalid input and follow through every programmed logic step in response to acceptable input. For
example, if testing customer validation and credit-checking procedures, the test data should include an
invalid customer number and a normal valid customer number, a transaction for a customer within their
credit limit, one already over their credit limit and another that would, if processed, exceed the credit limit.
All error and warning messages received from the system should be carefully recorded. Similarly, testing
the inventory system’s response to a sale of inventory should include a sale of an available item, one
where the sale should trigger the inventory replenishment supplier purchase order generation process, one
where the item is already on a supplier purchase order (to check that a duplicate purchase order is not cre­
ated) and one where there is insufficient stock available to supply the order (to test the back order process).
Testing of the payables process should include the following questions: does the system require a
three-way match of purchase order to receiving report and vendor invoice to authorise a disbursement?
If, when checking vendor invoices back to purchase order, a ‘tolerance’ is built in, is it reasonable?
(If the purchase order used the last purchase price and the vendor has increased prices by 5 per cent
since then, that is probably reasonable, and building in a 5 per cent tolerance will save a lot of manual
intervention to approve payment of a supplier invoice. However, allowing a 20 per cent tolerance may
be excessive.) Are all disbursements approved by two individuals entering approval codes? If so, is this
responsibility taken seriously or is it simply performed mechanically by the signatories? (This procedure
is clearly harder to check, particularly if individuals know that they are being observed by an auditor,
when they are more likely to ‘follow the book’.)
Test results should be fully documented and retained as part of the audit working papers.
The test data (usually known as a ‘test deck’, a name referring to the deck of punched cards orig­
inally used) should be retained for reuse after any modification to the system. When a modification

610 PART 4 Systems issues

has taken place, the entire system should be tested, not just the area modified. This is to ensure that no
inadvertent or fraudulent changes have been made to other areas.
Running test data through the system imposes several limitations on the auditors. For a start, if
the testing is performed using client staff, it will lessen the degree of independence. The testing
may be done on the ‘live’ system (i.e. when the system is in normal operating mode) or on a ‘dead’
system (e.g. after normal working hours). Testing may also be carried out on a copy of the production
system, supplied by the client to the auditors for that purpose. There is a small risk that, if there have
been any fraudulent modifications made to the production system, it may be restored to the original
state before performing a ‘dead’ system test or making a copy of the system for the auditors. If the
testing has been performed on the ‘live’ system, which is the more desirable situation, then after the
testing is complete all the test transactions should be reversed to remove them from the system. If it
was done on a ‘dead’ system, then the files would be simply rolled back to their previous status and
the changes discarded.
Integrated test facility (ITF)
A superior but more complex and expensive approach is to use embedded audit software. This is
software written by or for the auditor and embedded into the client’s computer system. The simpler
version is an integrated test facility (ITF). In this case, the auditors have reserved a range of cus­
tomer numbers, inventory numbers, supplier numbers and so on for test purposes and populated each of
these groups with ‘dummy’ records. They then run transactions using these records, merged in with the
­client’s normal transaction processing. The principal advantages of an ITF are that the auditors may be
assured that the test transactions are being processed in an identical manner to normal transactions and
it does not require the use of client staff. The principal disadvantage is the risk that adding these trans­
actions to normal processing may mean that they are included in summary totals, resulting in incorrect
totals appearing in client reports.
Embedded audit software
A more sophisticated example of embedded audit software is continuous auditing using a systems
­control and review file (SCARF). This method involves continuous review of all transactions passing
through the client’s system. It is used to draw auditor attention to ‘outliers’ in transactions that are note­
worthy by virtue of their size or because in some other way they differ significantly from the norm.
The auditor sets a series of parameters to identify such transactions warranting further investigation, for
example, in a payroll system all new or changed salary or wage payments over $10  000 per month. The
software will write all details of the transaction to the SCARF file, including the date and time, snap­
shots of before and after images of records updated, the user ID of the person entering the transaction
and the workstation ID of the terminal used. The auditor can then examine the transaction, comparing it
to the underlying records (in this case a payroll change authorisation form) to ensure that the transaction
has been correctly entered and has the required authorisation approval signatures. This type of software
often incorporates an off/on switch. Because examining all transactions passing through the system may
add to processing overhead, the client may pressure the auditor to only switch it on for limited periods.
Doing so obviously restricts its usefulness.
Generalised audit software
Generalised audit software (GAS) is software designed to read and process data, typically from
large databases, to perform a wide range of audit tasks. While the first two CAATs described pre­
viously are used dynamically to test the system in action and embedded audit software examines
transactions dynamically to identify those warranting further investigation, GAS is used statically
after the event to identify transactions or balances of interest to the auditor. This software is very
flexible and can read and extract data from a wide range of software running on all types of hardware
platforms. It can be used either to interrogate the client’s files on their own system or to copy the
client data from the source to the auditor’s own system for further analysis and processing. Typically,

CHAPTER 13 Auditing and governance of accounting information systems 611

this processing will involve selecting records for further investigation by the auditor. This may be a
selection of random samples of records using stratified statistical techniques, or a targeted selection
of records of particular interest or containing potential problems. Statistical sampling techniques are
outside the scope of this book. Records of particular interest will typically include ‘outliers’ that do
not conform to the normal pattern by virtue of size or frequency; or where there is an unexpected
volume of transactions for a particular customer or of a specific amount; or where there are abnormal
clusters of transactions in a particular range.
In a sales system, these may be, for sales invoices and credit notes or credit adjustments, the largest
and smallest percentile by dollar value and/or number of transactions; in accounts receivable, the largest
percentile by dollar value and age of debt; and in inventory, the largest percentile by dollar value and
slow stock turnover, and also items with negative quantity on hand or negative value. Examples of clus­
tered transactions are abnormally large numbers of credit notes in the range $450–$500 or abnormally
large numbers of capital expenditure items in the range $45  000–$50  000.
So, why are these records of particular interest to the auditor? The answer is that auditors’ natu­
rally suspicious natures and their previous experience have taught them that abnormal transactions
may have perfectly innocent explanations but also may be indicators of fraud or non-compliance with
corporate policies. High-value transactions are always of interest because a fraudulent high-value
transaction can cause greater loss than a fraudulent low-value transaction. Overdue receivable items
may be difficult or impossible to collect and therefore adequate provision for potential loss should
be made, and some of the slow-moving inventory may be unsaleable and should be written down in
value to allow for this. Credit notes and adjustments may be raised fraudulently to conceal the theft
of cash or theft of goods originally invoiced to fictitious customers. In the first clustered transactions
example it may be the case that a (dishonest) accounts receivable clerk has authority to authorise
credit notes up to a $500 limit. The second case may be where a plant manager has authority to
acquire capital expenditure items up to a $50  000 limit and has conspired with vendors to invoice
larger items in several parts to avoid compliance with more rigorous approval procedures required for
larger expenditures.
GAS may also be used to test for compliance with Benford’s Law, which demonstrates the counter­
intuitive fact that the first digits of most naturally occurring numbers fit into a non-uniform pattern.
Instinctively, we may believe that there is an equal 10 per cent probability of any number starting
with 1, 5 or 9. Benford’s Law47 shows there is a 30 per cent probability that the first digit will be 1,
and the probability decreases logarithmically until there is only a 5 per cent probability that the first
digit will be 9. As most people are unaware of this phenomenon, anyone creating a fraudulent list of,
for example, vendor invoices, is likely to instinctively create numbers with the first digits randomly
allocated.
In the United States in 1993, in State of Arizona v. Nelson (CV92-18841), the accused (a manager in
the State Treasurer’s office) was found guilty of trying to defraud the state of nearly US$2 million by
making fraudulent payments to a bogus vendor.48 The first digits of the fake invoices were mostly 7, 8
or 9. A routine test for compliance with Benford’s Law first drew the auditor’s attention to the problem.
GAS software can carry out normal arithmetical calculations on the entire data population or selected
samples, analyse the data statistically and produce reports in any required format.
Issues that may arise in using this type of software include whether the software can run on the live
production database, or whether instead data are copied by client staff to a test file for the auditor’s
use. This latter method means that the testing is slightly less independent as the copy process could be
corrupted, for example, by dishonest data-processing staff applying a filter to remove fraudulent trans­
actions from the test file before passing it to the auditor.
Many generalised audit software programs incorporate artificial intelligence and expert systems char­
acteristics, specifically the ability to ‘learn’ from previous experience. Over time, characteristics of the
database may change: such software will be able to identify what are now the unusual transactions
without specific direction.

612 PART 4 Systems issues

 Examples of generalised audit software include Audit Command Language (ACL), Interactive Data
Extraction and Analysis (IDEA), Activedata for Excel and TopCAATs for Excel.

Planning the audit

Planning includes all of the preparatory steps taken in advance of carrying out the fieldwork in an audit.
Good planning is an essential part of the audit process. The first step is deciding on the scope of the audit,
what is to be audited and what is the principal focus of the audit. If the AIS audit is a part of the statu­
tory audit process, then the scope is determined by the auditor. For any other type of audit, the scope is
agreed between the auditor and those instructing the auditor.
Planning is an iterative process; the plan and the audit program may be modified as needed as the
audit progresses. For example, if test results reveal an unsatisfactory level of control in one area, the
auditors may decide that it is necessary to carry out further testing not only in that area, but also in other
areas.

Studying the client and the industry

The next step in the planning phase is for the auditor to familiarise him or herself with the client’s
entire business and the industry in which it operates. This step is required to provide the auditor with
an understanding of any accounting practices or transactions unique to that industry. For example, to
minimise unused capacity, hotels and airlines offer different rates for the same room or seat by making a
limited number of rooms or seats available for sale at lower rates with more restrictive conditions. Such
a detailed understanding will help the auditor in deciding whether a particular transaction is within a
normal range or unusual, and if it requires further investigation.
This study will also allow the auditor to assess the control environment and the attitudes and capa­
bility of senior management. If the auditors believe that there is a strong control environment and capable
senior management acting with integrity, they will be more inclined to accept management assertions
about controls in place. From this study, they may also form an opinion as to whether there are circum­
stances that increase the inherent risk, which is the potential for fraudulent activity or serious and mat­
erial errors in financial statements. Such factors may include, and are not limited to, directors and senior
management integrity, directors and senior management skill and experience, external pressures arising
from market expectations, general economic conditions or those specific to the client’s industry, wors­
ening foreign exchange rates and severe, unusual climate conditions.

Studying the client’s system

The auditor next needs to study each of the system(s) under audit including system documentation,
broken down into the various business cycles and their component subsystems; for example, the revenue
cycle and its component sales, billing and accounts receivable subsystems and the expenditure cycle and
its component purchasing, payables, payroll and inventory management subsystems. This will involve,
for each component subsystem, studying all available process maps, data flow diagrams and systems
flowcharts, and any written descriptive material. In addition, the auditor will need to obtain samples of
the inputs and outputs of the system. The auditor should also observe the system in use and interview
a range of users at all levels, from managers to sales staff, to understand how the system operates in
practice. Often procedures have been modified officially or unofficially, and the documented system
may differ from the actual system in place. At this time, the auditor may consider the use of an internal
control questionnaire (ICQ). This is a standard form used by the audit firm, and is a checklist of ques­
tions for each business process. For example, in a retail environment, the cash sales process ICQ might
include: Is a register receipt issued for every sale? Does the register produce a daily or shift sales total?
Is the register assigned to a single staff member or multiple users? Who reconciles the cash collected to
the sales total? Who prepares the banking? Who performs the bank reconciliation? How are significant
cash shortfalls treated? Analysing the answers will help the auditor form a conclusion as to the strength
of the system. Some examples of ICQ questions are given in figures 13.1, 13.2 and 13.3.49

CHAPTER 13 Auditing and governance of accounting information systems 613

CLIENT Allied Industries Limited BALANCE DATE 30/6/16
Completed by: LRG Date: 12/3/16 Reviewed by: DRS Date: 29/4/16

Internal control questionnaire component: Control environment

Yes,
No,
Question N/A Comments

Integrity and ethical values

1. Does management set the ‘tone at the top’ by Yes Management is conscious of setting an example.
demonstrating a commitment to integrity and ethics Entity does not have a formal code of conduct.
through both its words and deeds?

2. Have appropriate entity policies regarding acceptable Yes Expectations of employees included in a policy
business practices, conflicts of interest, and codes manual distributed to all employees.
of conduct been established and adequately
communicated?

3. Have incentives and temptations that might lead to Yes Profit-sharing plan monitored by audit committee.
unethical behaviour been reduced or eliminated?

Board of directors and audit committee

1. Are there regular meetings of the board and are minutes Yes Board has nine inside members, three of whom
prepared on a timely basis? serve on the audit committee. Considering adding
three outside members to the board who would
2. Do board members have sufficient knowledge, Yes comprise the audit committee.
experience and time to serve effectively?

3. Is there an audit committee composed of outside No

directors?

Management’s philosophy and operating style

1. Are business risks carefully considered and adequately Yes Management is conservative about business risks.
monitored?

2. Is management’s selection of accounting principles and Yes

development of accounting estimates consistent with
objective and fair reporting?

3. Has management demonstrated a willingness to adjust Yes Management has readily accepted all proposed
the financial statements for material misstatements? adjustments in previous audits.

Human resource policies and practices

1. Do existing personnel policies and procedures result Yes Formal job descriptions are provided for all
in the recruitment or development of competent and positions.
trustworthy people needed to support an effective
internal control structure?

2. Do personnel understand the duties and procedures Yes

applicable to their jobs?

3. Is the turnover of personnel in key positions at an Yes Normal ‘turnover’.

acceptable level?

FIGURE 13.1 Excerpts from an internal control questionnaire — control environment

614 PART 4 Systems issues

CLIENT Allied Industries Limited BALANCE DATE 30/6/16
Completed by: LRG Date: 12/3/16 Reviewed by: DRS Date: 29/4/16

Internal control questionnaire component: CIS general controls

Yes, No,
Question N/A Comments

Organisational controls

1. Are the following duties segregated within the CIS department?

(a) Systems design Yes
(b) Computer programming Yes
(c) Computer operations Yes
(d) Data entry Yes
(e) Custody of systems documentation, programs and files Yes Good segregation in CIS department.
(f) Data control Yes

2. Are the following duties performed only outside the CIS department?
(a) Initiation and authorisation of transactions Yes
(b) Authorisation of changes in systems, programs and master files Yes
(c) Preparation of source documents Yes
(d) Correction of errors in source documents Yes
(e) Custody of assets Yes

Systems development and documentation controls

1. Is there adequate participation by users and internal auditors in new Yes Wide consultation.
systems development?

2. Is proper authorisation, testing and documentation required for Yes Strong controls in this area.
systems and program changes?

3. Is access to systems software restricted to authorised personnel? Yes

4. Are there adequate controls over data files (both master and Yes
transaction files) during conversion to prevent unauthorised
changes?

Systems development and documentation controls

1. Is access to computer facilities restricted to authorised personnel? No Facilities in unlocked area of main office.

2. Does the librarian restrict access to data files and programs to Yes
authorised personnel?

3. Are computer-processing activities reviewed by management? No More review by management needed.

Data and procedural controls

1. Is there a disaster contingency plan to ensure continuity of Yes

operations?

2. Is there off-site storage of backup files and programs? Yes

3. Are sufficient generations of programs, master files and transaction Yes

files maintained to facilitate recovery and reconstruction of CIS
processing?

4. Are there adequate safeguards against fire, water damage, Yes

power failure, power fluctuations, theft, loss, and intentional and
unintentional destruction?

FIGURE 13.2 Excerpts from an internal control questionnaire — computer information system (CIS) general controls

CHAPTER 13 Auditing and governance of accounting information systems 615

CLIENT Allied Industries Limited BALANCE DATE 30/6/16
Completed by: LRG Date: 13/3/16 Reviewed by: DRS Date: 29/4/16

Internal control questionnaire component: CIS general controls

Yes,
Question No, N/A Comments

Cash payments transactions

1. Is there an approved payment voucher with supporting Yes

documents for each cheque prepared?

2. Are prenumbered cheques used and accounted for? Yes

3. Are unused cheques stored in a secure area? Yes Safe in treasurer’s office.

4. Are only authorised personnel permitted to sign cheques? Yes Only treasurer and assistant treasurer can sign.

5. Do cheque signers verify agreement of details of cheque Yes

and payment voucher before signing?

6. Are vouchers and supporting documents cancelled after Yes Vouchers and all supporting documents are
payment? stamped ‘Paid’.

7. Is there segregation of duties for:

(a) approving payment vouchers and signing cheques? Yes
(b) signing cheques and recording cheques? Yes

8. Are there periodic independent reconciliations of cheque Yes Performed by assistant controller.
accounts?

9. Is there an independent check of agreement of daily No Comparison is now made by assistant treasurer;
summary of cheques issued with entry to cash payments? will recommend it be made by assistant controller.

FIGURE 13.3 Excerpts from an internal control questionnaire — cash payments

Developing the audit program

The next step is to expand the scope to a more detailed audit program. This will include an estimate of
the number and seniority of the staff needed and the time required to complete the audit.
At this stage, the auditor must assess the risks of misstatements or losses occurring. In the sales
system, possible risks are that a sale transaction may not be invoiced or an item may be priced incor­
rectly. The auditor then uses the knowledge obtained from studying the client’s system and any ICQs to
identify the controls in place to mitigate these risks. Controls addressing the second risk are using the
inventory master file to obtain prices and requiring a supervisor to enter a code to authorise additional
discounts. A useful way to record risks and controls is to create a risk–control matrix. This is a table
with risks recorded in the first column and controls recorded across the matrix. Where a control is iden­
tified as addressing a particular risk, a tick is placed in the cell where the risk and control intersect. In
most cases the relationship between risks and controls is many-to-many; each risk is addressed by more
than one control and each control addresses more than one risk. Studying the risk–control matrix may
highlight areas where controls appear to be weak or non-existent and suggest that the auditor include
those areas in the schedule of items for testing.
The audit program is essentially a checklist of all the tests and other procedures that the auditor
intends to carry out in order to form a judgement as to the reliability and integrity of the IS. The auditor
will form this judgement after evaluating the results of performing this test program.
The audit program will be carefully documented and retained for use in future periods, thus promoting
consistency from year to year.

616 PART 4 Systems issues

 The audit program should include substantive tests designed to verify the integrity of each of the
application systems. In addition, it should cover all aspects of the environment in which the system
operates.
Master audit programs
Most audit firms use a master audit program (MAP). This is a standardised program that has a large
number of ‘switches’ that may be set to customise the program for the particular client system; for
example, the parts of the program relating to the inventory system may be deactivated if the client is a
service organisation such as an educational institution. The advantages of a MAP include shortening the
preparation time and reducing the likelihood of omitting significant, desirable test procedures, providing
guidance for less experienced audit team members and ensuring a consistent approach by the audit firm
to all clients. Possible disadvantages include encouraging a ‘by the book’ attitude and curbing the urge
to follow up on ideas outside the scope of the MAP.

Fieldwork (performing the audit)

Fieldwork involves carrying out the tests identified in the planning stage described in the previous section,
either on site or in the auditor’s own offices. All instances of test failures should be fully documented and
recorded in a list of unresolved problems for later discussion with the client. Testing procedures and the
use of CAATs for performing substantive tests to verify program integrity were discussed in detail in the
audit tools section earlier in this chapter. It is also necessary to perform verification or confirmation testing.
Verification or confirmation testing
Verification or confirmation testing involves performing a series of tests for the auditor to be able to sat­
isfy themselves that the numbers in the accounts accurately represent the underlying reality. This method
will include such tests as, for inventory for example, obtaining assurance that the inventory recorded in
the computer system physically exists and is properly valued. To do this, the auditor will carry out both
an observation of the company’s stocktake procedures and a physical inspection of a sample of inventory
items to confirm that there are in fact X units of product Y in stock, and the unit value recorded of $Z
is appropriate. Testing receivables will involve confirming that, for each receivable recorded in the com­
puter system, the listed customer A exists and that the amount claimed is indeed owed by A to the client.
This test may entail, where possible, looking at external evidence that customer A (1) ordered the items
claimed to be supplied, and (2) received them. Such evidence may be in the form of a purchase order
and a delivery docket, each signed by or on behalf of A. It is also important to verify that the sales trans­
action is recorded in the correct accounting period as many frauds involve booking up sales at the end of
an accounting period to either increase revenue (and hence profits) in line with market expectations, or to
maximise bonuses and commission payments to dishonest employees. Such sales may either be genuine
sales but taking place in a future period, or nonexistent transactions reversed in the new financial year. One
test may involve looking for an abnormal number of credits issued in the first month of a financial year.
Testing payables will also incorporate procedures to ensure that all liabilities of the client have been
taken up in the accounts. The ‘cut-off’ procedure at the end of the financial year must be designed to
ensure that all invoices received in the first few weeks of a new year, but pertaining to transactions
incurred in the previous year, are properly recorded. It may also be necessary to adjust inventory records
where a vendor despatched and invoiced goods in the ‘old’ year but they were in transit at year-end and
received in the ‘new’ year. Again, management seeking to inflate profits may postpone recording vendor
invoices until the new year. Expense items are more likely to be subject to this fraud than physical inven­
tory as there may be no record of services having been performed by suppliers. One test may include
looking for abnormally high expenses in the first month of a financial year.
Again, instances of verification failures should be fully documented and recorded in the list of unre­
solved problems.
The selection of items for testing was discussed in the generalised audit software section earlier in
this chapter.

CHAPTER 13 Auditing and governance of accounting information systems 617

 Fieldwork also always involves spending time at the client’s site, observing procedures and conducting
interviews with managers and staff at all levels involved in the AIS. As part of the process, the auditor
will make copies of input documents and printouts created by the system under review.

Analysis
Analysis involves a careful study of the test outcomes, the interview notes and the documentation
accrued from fieldwork. While fieldwork and analysis are depicted as two sequential steps they are often
iterative; insights gained from analysis may demonstrate a need for further fieldwork. An important
analysis process is evaluating the system’s internal control.

Evaluating the system’s internal control

We described internal controls in chapters 8 and 9. The evaluation activities may be divided into three
broad areas: assessing the client’s overall control environment; establishing if the controls are appro­
priate and adequate for the system under review; and determining if the controls are working as intended.
This final activity is important, as in many cases controls may not be working as intended. For example,
a segregation of duties control may have been implemented in a small business where clerk A enters
customer receipts into the computer system and prepares the banking, and clerk B performs the bank
reconciliation. On the face of it, this control gives reasonable assurance that a theft of cash by A would
be detected by B. However, this control is circumvented by A and B agreeing between themselves, either
innocently or fraudulently, that A will do both tasks.
In studying the system, the auditor will have learned of the internal controls designed into the system.
The next stage is to test that they are in fact operating as intended. Internal controls can be subdivided
into management controls and programmed application controls. Assume that the sales system has a
management control over credit granting policy requiring that all decisions are documented in writing
and that sets the authorisation limit, and also has an application control that is designed to prevent any
sale being processed which would take the customer over limit.
The management control states that a new customer may be granted credit up to $2000 by a credit
department clerk on receiving a ‘no known problems’ report from an external credit bureau. Higher
credit limits require two written references in addition to the external credit check, and the application
must also be countersigned by the credit manager.
The management control may be tested by inspecting the documentation for a random sample of new
customers and ensuring that all the specified documents and required signatures are in place. The pro­
grammed application control may be tested by obtaining a list of customer balances and credit limits. If
the policy is enforced, there will be no over-limit customers.
Application control may be divided into the following five categories:
•• data entry and input controls
•• processing controls
•• output controls
•• database controls
•• e-commerce controls.
We will examine each of these categories in turn.
Data entry and input controls
Data entry and input controls are in place to ensure that all data captured are correct, complete, entered
only once and properly authorised by staff designated able to do so. Audit checks for the last item
(authorisation) may involve inspecting a sample of documents for authorisation signatures. The tra­
ditional input control was batch verification. Given that most twenty-first century systems are real-time
systems, batch control has little application. However, where it is applicable — for example, treating a
bank deposit total of cheques or direct credit payments received as a batch and reconciling the deposit
total to the total input — batch control is a useful control.

618 PART 4 Systems issues

 Data entry controls include verification against master files: when a data entry operator keys in a cus­
tomer number or product number, the customer or inventory details are displayed. The clerk can check
that the correct items are selected; if an incorrect customer or product is selected, the clerk can go back
a step, where an error message will be displayed if there is no record with that number.
Limit or reasonableness checks are programmed checks that may detect errors where the number is
almost certainly wrong. For example, in a single transaction a delicatessen may sell 500 g of ham but is
highly unlikely to sell 500 kg, and a factory worker may be paid $20 an hour but is unlikely to be paid
$2000.
Check digits is a control where a calculation is performed on some digits — and the result is another
digit. For example, the first five digits of a six-digit number are multiplied by various predetermined
numbers, the results are added, the sum is then divided by 11 and the remainder should equal the sixth
digit. This is a useful control when entering long numbers not originating from the organisation entering
them; for example, bank account numbers and tax file numbers both incorporate check digits. Check
digits will detect 99 per cent of errors such as digit transposition. The check digit algorithm is made
known to software developers, so that they can incorporate it in their software. As a result, attempts to
enter an invalid bank account number into a banking system or tax file number into a payroll system will
generate an error message.
Sequence numbers can also be used: if every transaction is allocated a sequence number on input, then
a sequence check can be run after processing and any missing transactions identified and investigated.
Processing controls
Processing controls are in place to ensure that transactions are processed completely and accurately.
The main processing control technique is the use of run-to-run controls. These are to ensure that correct
versions of master files are updated, and for every record updated (both at record level and master file
total level) the previous balance plus current transaction equals new balance.
Output controls
Output controls are in place to ensure that outputs are produced completely and accurately and distrib­
uted to the appropriate recipients in a timely manner. If there are no input errors and the system is pro­
cessing transactions correctly, then there should be no output errors. That said, in any system involving
fallible humans, errors occur, and some of these may be detected by physical inspection of the output.
Other significant controls include maintaining security over pre-printed cheque forms and the like,
ensuring that all outputs are delivered to users in a timely fashion, and that appropriate confidentiality is
kept over sensitive items, including shredding or other secure disposal of any additional copies of sensi­
tive material. Refer also to the discussion of output controls in chapter 9.
E-commerce controls
E-commerce controls are in place to ensure all e-commerce activities have effective internal controls.
Given the complexity of the systems involved, the rate of change in technology, the prevalence of
‘hacking’ and the widely publicised concerns over internet security, this is an area that requires more
coverage than is possible in a general-purpose text. As a minimum, the system should have a reliable
and available security system, require authentication of transactions, provide for the secure transmission
of credit card data, provide a safe, secure environment for the transfer of cash to and from the entity,
and maintain adequate evidence of transactions. Because there are significant risks in allowing unknown
persons access to an organisation’s computer system via its website, all possible precautions should be
taken. To minimise the risks, a company selling goods or services over the internet should, in conjunc­
tion with its bank, set up a secure website page for the transmission of credit card data direct to the bank.
The online sales system should pass the customer to that page when the customer clicks the ‘Order’
button. The bank will return the customer back to the sales system along with an approval number after
it has received the credit card data and verified that the card is valid and the transaction is accepted. The
client should not under any circumstances store customer credit card data on its own website as it could
be liable if it negligently allowed the data to be stolen by third parties.

CHAPTER 13 Auditing and governance of accounting information systems 619

 To endeavour to ensure that customers are who they declare themselves to be, the company can
require that new customers fill in a customer registration page, and the registration process emails the
customer, who then has to reply to finalise the registration. Additional security can be added by requiring
the customer to use a traceable email account and excluding customers using free email addresses from
providers such as hotmail.com or gmail.com.
General internet environmental controls are listed in the section on environmental controls later in this
chapter.
Application-specific internal control summary
Deciding whether the controls are appropriate and adequate for the system under review is a matter for
auditor skill and judgement. Testing that they are working as intended can be verified using test data.
Only after evaluating the effectiveness of the internal controls will the auditor be in a position to apply
skill and judgement in determining the nature, level and number of substantive tests needed to satisfy
him- or herself that the system is performing satisfactorily.
AIS Focus 13.3 examines some of the internal control issues that organisations need to consider in
relation to customer data.

AIS FOCUS 13.3

Protecting customer data

One of the key issues facing organisations is how to effectively secure and protect customer data.
Data breach
Hackers breached the Sony Online Entertainment (SOE) network as well as the PlayStation Network and
Qriocity streaming music service in April 2011. The SOE network is a network where users from around
the globe take part in massively multiplayer online role-playing games.
In one of the biggest data breaches on the internet, Sony reported that user details such as names,
home addresses, email addresses, birthdates, passwords and credit card details were stolen. This
affected up to 100 million customers.
Identity theft and brand damage
This data breach put individuals at risk of identity theft. It is estimated that the data breach cost Sony
$1 billion. The data breach also significantly impacted Sony’s brand image. Sony has assured cus-
tomers that it has improved its controls and has implemented an identity protection program, as well
as providing customers with an insurance policy if they are victims of identity theft. Will customers trust
Sony with their personal data?

Evaluating the system’s general infrastructure controls

Logical access controls
An audit program should involve testing access controls: Are passwords required for all logins? Are
these sufficiently complex? Are they changed periodically? Are users logged out automatically after
(say) 30 minutes inactivity? Are user IDs locked after (say) three unsuccessful logon attempts? Is an
access control log maintained and if so is it examined regularly? In reviewing access control logs, items
of interest may include unsuccessful attempts to gain access to areas of the system that a user was not
authorised to access or repeated unsuccessful logon attempts. Does the system extract and report sus­
picious events separately and promptly, for example, attempts to break passwords or logons outside
normal hours? Is the list of these events promptly reviewed and appropriate follow-up initiated? Are
terminated employees’ accounts disabled promptly?
Database controls
Database controls can take the form of access controls where the database administrator grants users
access to various files. Restricting access to those who need it to perform their work is an important part
of enabling adequate segregation of duties. As the database administrator has access to the entire system,

620 PART 4 Systems issues

he or she should not carry out any transaction processing. As part of the audit trail, these questions
need to be asked: Are database administrator activities recorded in a log file? If so, is that file regularly
reviewed by an independent third party?
Performing regular file dumps and setting up checkpoints to enable data recovery in the event of a
system crash are essential controls.
Ensuring that there is an adequate audit trail is also essential. An audit trail should contain, for every
transaction processed, the date and time, details of the transaction and the before and after images of
records updated, as well as the user ID of the person entering the transaction and the work station ID of
the terminal used.
If the transaction is initiated over the internet, then the URL of the other party should be recorded.
Physical environmental controls
There are a number of issues about which the auditor should seek to obtain management assurances.
•• Is the physical environment secure? Risks include theft, vandalism, sabotage.
•• Is there an adequate fire prevention/detection/extinguishing system in place?
•• Are all possible actions to prevent flood damage in place?
•• Is there adequate air conditioning to protect equipment at all times?
•• Is there an adequate uninterruptible power supply (UPS) to permit ‘graceful degradation’ of the
system (i.e. completing processing and saving of all current transactions, and setting up checkpoints
to facilitate restoration of data)?
The auditor should also review contingency plans: Does the client have an adequate, regularly updated
disaster recovery plan? Does this include insurance cover at current replacement cost? Are the actions
proposed in this plan tested regularly?
Environmental controls should also ensure adequate backup procedures are in place, including off-site
storage of backups of critical data. The auditor should also ask whether the capability of restoring the
system from backup files is tested regularly.
Other questions the auditor should ask include the following.
•• Is all software properly licensed?
•• Are appropriate information system security policies, procedures and equipment in place? This
measure is particularly important if the client conducts business over the internet. These controls
should include, but are not limited to, current antivirus software, encryption, physical and logical
firewalls, invasion detection software, protection against denial-of-service attacks and so on.
Storage controls
Control over storage media has two aims: to ensure that stored data is kept safe from accidental or delib­
erate destruction, and to prevent unauthorised disclosure of data, particularly when it is of a private or
confidential nature. Controls include restricting access to data as discussed in the logical access controls
subsection, and controls to ensure that all discarded storage media are erased before disposal.
Questions should also be asked concerning portable equipment: are there adequate physical security
controls over hardware, particularly laptops? If sensitive data is stored or used on laptop hard drives, is
it encrypted to avoid misuse of the data should the laptop be lost or stolen? This is not a trivial issue; the
New Zealand Inland Revenue Department revealed that it had ‘lost’ more than 100 laptops over a period
of one year, and concerns were raised that these may have contained sensitive taxpayer data, although the
department claimed that this was not the case.50 Similar concerns apply to USB memory sticks, which
are more frequently carried around and are easier to mislay than laptops. A UK police officer in the West
Midlands was reported to have lost an unencrypted memory stick containing top-secret information on
terror suspects.51
Change controls
The nature of computing is that changes occur often. Changes may be planned (e.g. implementing an
updated version of a software product) or unplanned (e.g. responding to a crisis situation when a pro­
gram has crashed). The auditor should ensure that there are proper protocols for making changes (even

CHAPTER 13 Auditing and governance of accounting information systems 621

in emergency situations). These include authorisation, documentation, ensuring that security is not com­
promised and, whenever possible, leaving an escape route where a change can be wound back to revert
to the pre-change state if unforeseen problems occur.

Completion, review, monitoring and reporting

On completion of the audit, the auditors are required to complete a review process, usually undertaken
by senior supervisors, and to attest to the accuracy of the data audited in a reporting procedure. These
tasks are discussed further in the following sections.
Analytical review
Auditors will normally wish to perform an analytical review. This is a process involving analysing trans­
actions in a database and identifying relationships. These relationships may be within the same client data­
base for the current year, or the same client in earlier time periods, or comparing this client with industry
norms. Having identified what is ‘normal’, the auditor may then examine, for example, the database of
sales transactions and look for items that do not conform to the general trend. If the client company has a
normal gross profit rate of 20 per cent of sales, then transactions with a gross profit rate of less than 10 per
cent could be regarded as exceptional and pulled out for investigation. Of course, adequate explanations
may be forthcoming: they could have been loss leaders, discounted during sales, or damaged or obsolete
stock, but equally they could have been mispriced accidentally or deliberately as part of a fraud scheme.
The analytical review is designed to highlight any transactions that may be unusual, based on more over­
arching cross-transactional criteria than previously used in the testing procedures.
Completion and review
Where the AIS audit forms part of the normal external audit, the completion procedures and the
reporting process described in the following section are part of the wider audit completion process, and
are an adaptation of the process described here. These processes can be divided into two sections: those
involving the client and those internal to the auditors.
The list of unresolved problems generated by the testing program will usually be worked through with
the client: some may turn out to be trivial and possibly a consequence of auditors not appreciating what
was being done in the system, and others may be minor and included for subsequent action in a man­
agement letter written at the conclusion of the audit. Some may be major and of sufficient magnitude to
impact on the auditor’s overall conclusions about the integrity of the AIS processes.
Because of the hierarchical nature of audit teams, the internal part of the completion process is usually
a review of work done by team members, carried out by their immediate supervisor. Thus, senior audi­
tors review the work of their juniors; managers review seniors; and the partner in charge reviews man­
agers. These reviews are designed to demonstrate that all the tasks as set out in the audit program have
been completed with an appropriate level of professional care and skill, that all items on the list of unre­
solved problems have been dealt with as far as possible, and that the results of all audit activities have
been fully documented and any judgements (particularly adverse findings) can be fully justified.
Monitoring, reviewing and closure
This phase includes ensuring that any dummy data created during the audit is removed from the client’s
active system and that all the audit files are properly closed. It also includes preparing detailed notes
ready for the next audit. The reviewing activities largely comprise ensuring that management has, in fact,
made the changes to the system that they had earlier promised to do. The monitoring activities ensure
that the changes are in place and working as designed.
Reporting
The last step in the review process is to report to those to whom the terms of engagement have specified.
In the case of the external audit, the report is nominally addressed to the shareholders but is, in practice,
presented first to the directors. The auditor is required to state whether or not, in their opinion, the accounts

622 PART 4 Systems issues

give a true and fair view of the company’s activities for the period under review, and whether or not the
accounts have been prepared in accordance with generally accepted accounting principles (GAAP). In
any other case, this report will typically be submitted to either the board of directors or its audit committee.
Presumably, such a report will be commissioned with a view to finding and correcting any weaknesses,
particularly those actually giving rise to material misstatements and errors, or with the potential to do so.
Therefore, the report should be prepared at a level of detail to enable appropriate corrective action to be
taken. In either case, the report will normally go through several revisions before final submission, particu­
larly if the findings are adverse or the recommended future changes to procedures are considered by the
client to be unduly onerous. There may be a need for judgement to be exercised to negotiate a compromise
between what should be included in the auditor’s view and what is acceptable to and likely to be acted
on by the client. In addition to the formal audit report, the auditor normally also prepares a management
letter detailing errors requiring adjustment found in the course of the audit and required improvements to
controls. These items may be addressed progressively during the audit process and the final report may be
issued contingent upon management undertaking to rectify the situation.

Audit of systems under development

A strong case can be made for auditors to be involved in the design and development of new systems.
The auditor will need to be assured that all possible risks arising from the use of the new system have
been identified and that appropriate controls will be included to mitigate these risks. It is critical that
controls are incorporated in the design phase, at which stage the cost of their inclusion is minimal com­
pared with the costs involved in subsequently modifying the system when it is operating. In addition,
there may be large but unquantifiable costs resulting from exposure to the risks posed by missing con­
trols. The auditor will also either be involved in testing the new system or, at the very least, be required
to review the test plans to ensure that all possible risk factors are included and tested for, and also to
review test results to confirm that all controls are in place and working as intended.
In addition, auditors may be appointed by senior management to audit the entire project development, to
provide management with an independent opinion of the project progress in contrast to the possibly ‘rose-
tinted’ views of the project team leadership. Such an audit will involve most or all of the following activities:
•• ensuring that the project and its funding have been approved by senior management, and that
management are committed to and supportive of the project
•• ensuring that the project team’s leaders are qualified to undertake the implementation of the project
•• reviewing user requirements documentation, and being assured that the projected system will meet
these requirements
•• monitoring actual progress against projected completion dates for milestones
•• monitoring project expenditures against budget, and seeking explanations for significant overspending
•• reviewing documentation and verifying that all required documents, including user manuals, have
been prepared and are kept current as the system is modified during development
•• ensuring that all necessary approvals have been granted.

Special purpose audits

Special purpose audits may be commissioned by management to:
•• investigate proven or suspected fraud by employees or others (e.g. customers or vendors) with access
to the client’s system
•• investigate intrusion (hacking) into a system — attempted intrusion may be to introduce viruses or
Trojan horses, sabotage the system or steal data
•• obtain an independent opinion of the system’s possible vulnerability to such events.
In such cases there is no uniform approach; the auditor’s approach will be dictated first by the terms of
engagement and second by the particular circumstances of the client. Required skill sets will include a strong
knowledge of IT generally and IT security specifically, particularly relating to the type of system(s) used by the
client. Additional skills needed may vary from those of a fraud squad detective to those of a criminal hacker.

CHAPTER 13 Auditing and governance of accounting information systems 623

SUMMARY
13.1 Appraise the importance of the audit function to good corporate governance.
Internal control and risk management are crucial to effective corporate governance. Corporate risk
involves all aspects of the business, including business continuity, financial performance, intellectual
property, fraud and corporate governance. There are a number of ways professional auditors provide
audit and assurance services to enhance corporate governance. These include the internal audit function,
external audits and the audit committee.
13.2 Summarise the role of internal audit.
The internal audit function is all-encompassing and involves much more than the evaluation of finan­
cial information. It includes the evaluation of controls in business processes, information systems and
systems development projects. There is a close relationship between the internal auditing function and
the organisation’s external (outside) auditors.
13.3 Explain the function of external audit.
An external audit is a regulatory mandate; that is, government legislation requires that organisations
undertake external audits that provide an independent opinion of the financial accounts.
13.4 Summarise the role of the audit committee in evaluating corporate governance.
An independent audit committee is a fundamental component of a good corporate governance structure.
The audit committee has the responsibility for monitoring and overseeing the organisation’s audit pro­
cesses including internal control activities.
13.5 Critique the influences on the auditor.
Auditing standards come under the control of the Auditing and Assurance Standards Board (AUASB).
Australian Auditing Standards (ASAs) are legally binding auditing standards, issued by the Australian
Auditing and Assurance Standards Board, which set out audit requirements for listed companies under
the Corporations Act. Sources of best practice include ISO standards and materials and procedures
developed by the vendors and firms that offer audit and assurance services.
13.6 Explain the importance of the financial audit.
A financial audit is an examination of the financial report (consisting of the balance sheet, an income
statement, a statement of changes in equity, a cash flow statement, and notes comprising a summary
of significant accounting policies and other explanatory notes) to form a view independently from the
organisation as to the reliability of that information. This is important for the users of financial reports
to make reliable decisions.
13.7 Evaluate the functions of an IS audit.
An information systems (IS) audit is part of the overall audit process and is important for good corporate
governance. The risk-based approach is commonly used to utilise resources efficiently. Audit tools fall
into two categories: internal control frameworks and computer auditing tools and techniques, generally
known as CAATs. Audit tools and techniques assist the auditor in assessing risks.

KEY TERMS
Analytical review A process that involves analysing transactions in a database and identifying relationships.
Attest service An independent accountant expressing a written opinion about the reliability of a
written assertion prepared by another party.
Audit A systematic process of objectively obtaining and evaluating evidence regarding assertions
about economic actions and events to ascertain the degree of correspondence between those
assertions and established criteria and communicating those results to interested users.

624 PART 4 Systems issues

Audit trail A traditional method that auditors used to follow a paper ‘audit trail’ from source
documents to final accounts and vice versa.
Australian auditing standards (ASAs) ASAs establish requirements and provide explanatory
guidance on the responsibilities of the auditor and the assurance practitioner, as appropriate, in audit
and assurance engagements.
CAATs The tools and techniques employed by auditors to extract and analyse client data.
Embedded audit software Software written by or for the auditor and embedded into the client’s
computer system.
Generalised audit software (GAS) Software designed to read and process data, typically from large
databases, to perform a wide range of audit tasks.
Generally accepted accounting principles (GAAP) Accepted conventions, rules and procedures that
define accounting practice.
Inherent risk The potential for fraudulent activity or serious and material errors in financial
statements.
Integrated test facility (ITF) A simple version of embedded audit software that populates a client’s
system with ‘dummy’ records.
Internal control questionnaire (ICQ) A standard form used by an audit firm to evaluate internal
control procedures comprising a checklist of questions for each business process.
Master audit program (MAP) A standardised program that has a large number of ‘switches’ that
may be set to customise the program for the particular client system.
Purpose of an audit To enhance the degree of confidence of intended users in the financial report.
This is achieved by the expression of an opinion by the auditor on whether the financial report is
prepared, in all material respects, in accordance with an applicable financial reporting framework.
Sarbanes–Oxley Act (SOX) US legislation that requires generally higher standards of financial
reporting. The Act is binding on subsidiaries of US companies. SOX applies to all public companies
in the US and non-US companies issuing and registering securities in the US.
Systems control and review file (SCARF) A sophisticated example of embedded audit software that
involves continuous review of all transactions passing through the client’s system.
Test data Also known as a test desk. A name referring to the deck of punched cards originally used
by the auditor to test the integrity of the program and systems, and the information contained within
them.
True and fair view A legally required and binding statement from an auditor attesting to the accuracy
of a company’s financial statements for the period under review.

DISCUSSION QUESTIONS
13.1 Explain the importance of an audit to corporate governance.(LO1)
13.2 Discuss the two broad areas of risk management.(LO1)
13.3 How does internal audit contribute to good corporate governance?(LO2)
13.4 What is the relationship between the internal and the external auditors?(LO3)
13.5 Explain the role of the audit committee in an organisation.(LO4)
13.6 Outline the influences on an auditor.(LO5)
13.7 Describe the objectives of a financial audit.(LO6)
13.8 What skills and capabilities do AIS auditors need to effectively undertake IS audits?(LO7)
13.9 How is an audit program developed?(LO7)
13.10 What are the tools and techniques used by AIS auditors?(LO7)
13.11 What do you consider to be the principal advantage of using an internal control
questionnaire?(LO7)
13.12 Explain the use of a systems control and review file (SCARF).(LO7)

CHAPTER 13 Auditing and governance of accounting information systems 625

13.13 Why is check digit verification a more useful control when the number does not originate
from the organisation entering it than it is for locally generated numbers?(LO7)
13.14 Why is control strengthened if the database administrator is not allowed to perform any
transaction processing?(LO7)
13.15 If there are no problems with the system, why should staff spend time and effort restoring
the system from backup files?(LO7)
13.16 Why is it more desirable to run test data through the ‘live’ system than the ‘dead’ system?(LO7)
13.17 What is the prime purpose of maintaining a list of unresolved problems during the
testing phase of an audit?(LO7)
13.18 Explain why many accounting firms use a ‘master audit program’. (LO7)
13.19 During fieldwork, auditors conduct interviews with client staff at many levels.
Why do they not simply interview the person in charge of the relevant section?(LO7)
13.20 Why is there often tension between the auditor and the client over what is
to be included in the final report and accompanying management letter?(LO7)
13.21 Explain why it is necessary for the auditor to conduct post-audit monitoring.(LO7)

SELF-TEST ACTIVITIES
13.1 Which of the following is not an advantage of using a master audit program?(LO6)
(a) It will typically shorten the audit program preparation time.
(b) It will curb the urge to follow up on ideas outside the scope of the MAP.
(c) It will provide guidance for less experienced audit team members.
(d) It will lessen the likelihood of omitting significant desirable test procedures.
13.2 Which of the following is not a feature of using a generalised audit software package?(LO7)
(a) It can be used to produce reports in any required format.
(b) It can be used to generate a random sample of records using statistical techniques.
(c) It must be run on a copy of the production database.
(d) It may incorporate artificial intelligence and expert systems characteristics.
13.3 Which of the following is not likely to increase the inherent risk?(LO7)
(a) Director and senior management inexperience.
(b) Worsening general economic conditions.
(c) Improving foreign exchange rates.
(d) External pressures arising from market expectations.
13.4 In a company with fewer than 200 employees, client personnel procedures require that,
for all new employees earning over $60  000 per annum, the new employee authorisation
form is approved by the personnel manager in writing. As an auditor, how would you test
the operation of this control?(LO7)
(a) Inspecting the new employee authorisation forms for all of those employees.
(b) Interviewing the personnel manager.
(c) Obtaining from the computer system a printout of all new employees and inspecting it.
(d) Inspecting the new employee authorisation forms for a sample of those employees.
13.5 Which of the following are classed as application controls?(LO7)
(a) E-commerce controls.
(b) Processing controls.
(c) Database controls.
(d) All of the above are classed as application controls.
13.6 Which of the following is not an access control?(LO7)
(a) Disabling terminated employees’ accounts promptly.
(b) Storing backup files off-site.

626 PART 4 Systems issues

 (c) Logging inactive users out automatically.
(d) Reviewing the access control log.
13.7 Which of the following is not a test to detect schemes to fraudulently increase profit?(LO7)
(a) Looking for an abnormal number of credits issued in the last month of a financial year.
(b) Overvaluing or double-counting inventory.
(c) Checking for vendor invoices covering transactions occurring in the ‘old year’
not brought to account until the ‘new year’.
(d) Failing to write off inventory which has been discarded, stolen or scrapped.
13.8 An analytical review may involve identifying relationships:(LO7)
(a) by comparing this client’s data for the current year with industry norms.
(b) within the same client database for the current year.
(c) by comparing this client’s data for the current year with this client’s data
in prior time periods.
(d) all of the above.
13.9 Sarbanes–Oxley Act requirements include:(LO6)
(a) a prohibition on the audit firm carrying out non-audit services.
(b) mandatory rotation of lead audit partners.
(c) an internal control report including a statement of management’s responsibility for
establishing and maintaining adequate internal control.
(d) all of the above.

PROBLEMS
13.1 Research the Centro directors case (discussed in this chapter). Debate the pros and
cons of the penalties applied by the court.(LO3)
13.2 Research the topic ‘rotating audit firms’. What are the issues associated with this topic?(LO3)
13.3 Investigate the status of the BBY collapse. Write a report explaining the BBY collapse
and the role the audit committee should have taken to avoid this happening. (LO4)
13.4 Investigate recent examples of cheating. This could include providing false CVs, cheating
at university by paying for assignments to be written or cheating on tests (workplace or
educational setting). Write a report that outlines the issues relating to cheating for
business. In your answer provide specific examples. (LO3, LO4)
13.5 The Blue Chip Bank is a major trading bank with branches and ATMs throughout Australia
and New Zealand. Blue Chip issues its customers with debit cards, termed Blue Cards, to use
in ATMs and for EFTPOS transactions.
Within Blue Chip’s credit card department there is a card control sub-unit that deals with a
range of problems. These include:
• reviewing ATM transaction logs and identifying and investigating potentially suspicious
transactions
• handling cards returned by postal services marked ‘Gone No Address’
• resetting PINs for customers with poor memories
The bank automatically mails out new cards to customers every two years. The returned card
process involves making every possible attempt to contact the customer, using mobile phone
numbers, employers and so on. If these prove ineffective and the account is not in current use, it
is declared ‘dormant’ and deactivated.
Michael Brook, the head of the card control sub-unit, was recently arrested and charged
with fraud. Brook found a returned card for which he was unable to locate the customer. The
account was not in current use but had a large balance, so he reset the PIN, increased the daily

CHAPTER 13 Auditing and governance of accounting information systems 627

 withdrawal limit from the default $400 to the maximum of $2000 and used the card at ATMs
to withdraw all the cash from the account. Brook’s fraud was not discovered by the bank or its
auditors but was reported by his wife, incensed on discovering that he was spending the stolen
money on other women.
As the new head of internal audit for Blue Chip Bank, identify the control weaknesses
that Brook exploited and explain the changes in procedure that you recommend to prevent a
repetition. (LO2, LO6)
13.6 You are a member of the team of an audit firm that is auditing Boomerang, a retail clothing
chain with stores in major shopping malls throughout Australia and New Zealand. You have been
assigned the task of testing the supplier invoice data entry and approval process for non-inventory
items. Details of the system are:
• All accounting is done at the group head office and suppliers are instructed to mail their
invoices there directly.
• Orders for non-inventory items are issued by store staff. The person ordering enters the first
three letters of the vendor name. The system displays a list of all vendors starting with those
letters, together with their corresponding short codes, and the person ordering selects the
required vendor.
• Required order details are entered as shown in the tables following.
The system carries out the following edit checks:
– Vendor short code corresponds to existing vendor (existence check)
– Quantity and unit price numeric (format check)
– Total purchase order value < $500 (limit check)
– There are uncommitted funds in budget for selected expense code (authorisation check).
• Orders are automatically added to the open order file at group head office.
• When the items are received, the store updates the order file to set the received status
to Yes.
• The system also provides for standing orders for regular transactions. These are automatically
generated each month and the received status is not checked for these.
• When entering a vendor invoice, the accounts payable clerk selects the vendor as previously
described.
• The system displays all outstanding orders for that vendor. The clerk selects the required order.
The system displays all order details on file as shown in the tables below, except for Unit Price
and Received fields.
• The clerk enters the following data from the invoice: invoice date, invoice number, due date
and unit price (for each item). The system checks the price entered against the file price. If
the price entered is less than the file price, or exceeds the file price by 5 per cent or less, the
system updates the file price. If it exceeds the file price by more than 5 per cent, the system
routes the transaction to the purchasing manager who must enter an override code before the
transaction will be accepted into the system.
• For normal invoices, if the received status is not Yes, the transaction will be rejected.
The clerk will have to contact the store, and if necessary the store will update the
order file.
• The system calculates and displays the invoice price, including GST and any other applicable
taxes. The clerk checks the invoice total against the calculated total. If these differ, the clerk
has to investigate the difference, otherwise the clerk accepts the transaction, which authorises
the system to pay the vendor on the due date. (LO3, LO7)
Required
Make up test data for ten simulated orders that a branch may make and ten simulated vendor
invoices to test that the system is acting correctly as described, using the data in the tables
on next page.

628 PART 4 Systems issues

Vendor table
Vendor code Vendor name
COF305 Coffee Supplies
CON249 Consolidated Plastics
CON077 Control Systems
CON021 Convergent Technology

Store table
Code Store
1038 Cairns
2013 Canberra
3067 Carnegie
5790 Chatswood
6702 Christchurch
4690 Coolangatta

General ledger codes table

GL code Expense
7893 Plastic carrier bags
7832 Tape
7822 Tissue paper
5034 Staff refreshments
5697 Telephone rental
5618 Local call charges
5847 Security alarm monitoring

Purchase order file structure

Field Comments
Order Number System generated
Order Type Values N(ormal) or S(tanding)
Order Date System supplied
Store System supplied
Quantity Repeating group
Unit of Measure e.g. dozen, 100, 1000
Description
Unit Price
Received Values Yes / No / NA (for standing orders)
Vendor Code
Gl Code

CHAPTER 13 Auditing and governance of accounting information systems 629

 13.7 You are a manager in the team of an audit firm that is auditing Boomerang, a retail clothing
chain with stores in major shopping malls throughout Australia and New Zealand. You have
been assigned responsibility for confirmation of the client’s valuation of the inventory held at its
distribution centre.
The structure of the client’s inventory master file is:

Item number
Description
Size
Colour
Quantity on hand
Weighted average cost
Last cost
Vendor code
Economic order quantity
Reorder point
Quantity issued for year
Quantity purchased for year

The client has had stock count sheets prepared in duplicate with the first four fields
above filled in and a blank space for quantity on hand to be written in. Client staff are
about to count the inventory and complete the stock sheets. The second copies were
given to you. (LO3, LO7)
Required
How do you plan to go about substantiating the client’s inventory valuation, assuming that you
have a comprehensive generalised accounting software package available?
13.8 Investigate SOX compliance and how it influences Australian companies.
Write a report on the key influences, including SOX, for management and boards.(LO5)
13.9 Read the following document: ISACA, ITAF™: A Professional Practices Framework
for IS Audit/Assurance, 3rd edition, 1 November 2013 (www.isaca.org/Knowledge-Center/
Research/Documents/ITAF-3rd-Edition_fmk_Eng_1014.pdf). Explain what is meant by
a risk-based audit approach.(LO7)
13.10 Read the following article on The Conversation: ‘Why companies have little incentive
to invest in cybersecurity’ by Benjamin Dean (https://theconversation.com/why-companies-
have-little-incentive-to-invest-in-cybersecurity-37570). Write a report that explains how
the risk assessment process either supports or doesn’t support this author’s views.(LO4)

FURTHER READING
Bierstaker, J, Janvrin, D & Jordan Lowe, D 2013, ‘What factors influence auditors’ use of computer-
assisted audit techniques?’, Advances in Accounting, vol. 30, no. 1, pp. 67–74.
Carson, E, Redmayne, NB & Liao, L 2014, ‘Audit market structure and competition in Australia’,
Australian Accounting Review, vol. 24, iss. 4, pp. 298–312.
Chan, DY & Vasarhelyi, MA 2011, ‘Innovation and practice of continuous auditing’, International
Journal of Accounting Information Systems, vol. 12, iss. 2, pp. 152–60.

630 PART 4 Systems issues

Fogarty, TJ & Rigsby, JT 2010, ‘A reflective analysis of the “new audit” and the public interest: the
revolutionary innovation that never came’, Journal of Accounting & Organizational Change, vol. 6,
iss. 3, pp. 300–29.
Leung, P, Coram, P, Cooper, BJ & Richardson, P 2011, Modern auditing and assurance services,
5th edn, John Wiley & Sons Australia Ltd, Brisbane.
Nor, JM 2010, ‘Fraudulent financial reporting and company characteristics: tax audit evidence’,
Journal of Financial Reporting & Accounting, vol. 8, iss. 2, pp. 128–42.

SELF-TEST ANSWERS
13.1 b, 13.2 c, 13.3 c, 13.4 a, 13.5 d, 13.6 b, 13.7 a, 13.8 d, 13.9 d

ENDNOTES
1. American Accounting Association, Committee on Basic Auditing Concepts 1973, A statement of basic auditing concepts,
Sarasota, FL.
2. Australian Accounting Standards Board (AASB) 2013, Compiled Auditing Standard ASA 200 Overall Objectives of the
Independent Auditor and the Conduct of an Audit in Accordance with the Australian Auditing Standards, para. 3.
3. ASX Corporate Governance Council 2014, Corporate governance principles and recommendations, Third Edition, Australian
Securities Exchange Limited, Sydney, p. 3, www.asx.com.au/documents/asx-compliance/cgc-principles-and-recommendations-
3rd-edn.pdf.
4. Standards Australia 2009, AS/NZS ISO 31000:2009, www.standards.org.au.
5. Institute of International Auditors 2011, International Professional Practices Framework (IPPF), Institute of Internal Auditors,
Florida, USA.
6. AASB 2013, Auditing Standard ASA 610 Using the Work of Internal Auditors, para A1, www.auasb.gov.au.
7. AASB 2013, Auditing Standard ASA 610.
8. AASB 2013, Auditing Standard ASA 700 Forming an Opinion and Reporting on a Financial Report, www.auasb.gov.au.
9. ASIC 2014, ‘Audit quality — the role of directors and audit committees’, http://asic.gov.au/regulatory-resources/
financial-reporting-and-audit/auditors/audit-quality-the-role-of-directors-and-audit-committees/#roles.
10. AASB 2011, Auditing Standard ASQC1 Quality Control for Firms that Perform Audits and Reviews of Financial Reports and
Other Financial Information, and Other Assurance Engagements, 27 June, www.auasb.gov.au.
11. Carson, E, Redmayne, NB & Liao, L 2014, ‘Audit market structure and competition in Australia’, Australian Accounting
Review, vol. 24, iss. 4, p. 307.
12. ASIC n.d., ‘Audit inspection and surveillance programs’, http://asic.gov.au/regulatory-resources/financial-reporting-and-audit/
auditors/audit-inspection-and-surveillance-programs/.
13. Morgan, E 2015, ‘BBY collapse: firm may have been insolvent as early as June 2014, administrators say’, ABC News, 12 June,
www.abc.net.au/news/2015-06-12/bby-may-have-been-insolvent-since-june-2014-kpmg-says/6543062.
14. ASIC n.d., ‘Directors — consequences of insolvent trading’, http://asic.gov.au/regulatory-resources/insolvency/
insolvency-for-directors/directors-consequences-of-insolvent-trading/.
15. See www.austlii.edu.au/au/cases/cth/FCA/2011/717.html.
16. Lannin, S 2011, ‘Centro boss fined for breach of corporate law’, ABC News, 31 August, www.abc.net.au/news/2011-08-31/
centro-boss-fined-for-breach-of-corporate-law/2864618.
17. Auditing and Assurance Standards Board, Australian Institute of Company Directors and the Institute of Internal Auditors-
Australia 2012, Audit committees: a guide to good practice, Second Edition, p. 1, www.companydirectors.com.au/~/media/
Resources/Director%20Resource%20Centre/Publications/Books/Books%20content%20campaigns/Audit%20Committees%20
2nd%20Edition%20Chapter%201%20extract.ashx.
18. Governance Institute of Australia 2014, ‘Good governance guide: issues to consider when constituting audit and risk
committees’, www.governanceinstitute.com.au/media/651535/ggg_issues_consider-audit_risk_committees.pdf.
19. Auditing and Assurance Standards Board, Australian Institute of Company Directors and the Institute of Internal Auditors-
Australia 2012, Audit committees: a guide to good practice, Second Edition, p. 1, www.companydirectors.com.au/~/media/
Resources/Director%20Resource%20Centre/Publications/Books/Books%20content%20campaigns/Audit%20Committees%20
2nd%20Edition%20Chapter%201%20extract.ashx.
20. Australian National Audit Office, ‘Introduction’, www.anao.gov.au/html/Files/BPG%20HTML/BPG_
PublicSectorAuditCommittees/1_introduction.html.

CHAPTER 13 Auditing and governance of accounting information systems 631

21. Auditing and Assurance Standards Board, Australian Institute of Company Directors and The Institute of Internal Auditors-
Australia 2012, pp. 5–6.
22. Auditing and Assurance Standards Board (AUASB) 2006, Auditing Standard ASA 100 Preamble to AUASB Standards,
www.auasb.gov.au.
23. For an extensive list, see www.iso.org/iso/home/store/catalogue_ics/catalogue_ics_browse.htm?ICS1=35&ICS2=20.
24. US Securities and Exchange Commission 2003, ‘Final rule: management’s reports on internal control over financial reporting
and certification of disclosure in exchange act periodic reports’, Release no. 33-8238, 5 June, www.sec.gov.
25. It is generally believed that the Enron auditor, Arthur Andersen, allowed the Enron audit partners and senior staff to become
too close to Enron executives, compromising their independence and, in turn, leading to the issue of unqualified reports and
allowing the fraud to grow exponentially and continue for longer than may otherwise have been the case.
26. Public Company Accounting Oversight Board (PCAOB) 2009, ‘Our mission’, www.pcaobus.org.
27. Public Company Accounting Oversight Board (PCAOB) 2007, Auditing Standard No. 5 An Audit of Internal Control Over
Financial Reporting That Is Integrated with An Audit of Financial Statements, 27 July, p. 397.
28. PCAOB 2007, p. 397.
29. PCAOB 2007, p. 427.
30. Parker, R 2010, ‘Business skills for the IT audit and assurance professional’, ISACA Journal, vol. 3, www.isaca.org.
31. Sayana, SA 2002, ‘The IS audit process’, ISACA Journal, vol. 1, www.isaca.org.
32. ISACA fact sheet, ‘About ISACA’, www.isaca.org.
33. ISACA 2013, ITAF™: A Professional Practices Framework for IS Audit/Assurance, 3rd Edition, 1 November, www.isaca.org/
Knowledge-Center/Research/Documents/ITAF-3rd-Edition_fmk_Eng_1014.pdf.
34. ISACA 2010, IT standards, guidelines, and tools and techniques for audit and assurance and control professionals,
www.isaca.org.
35. ISACA 2013, ITAF™: A Professional Practices Framework for IS Audit/Assurance, 3rd Edition, section 2.4 Audit Risk, 1
November, www.isaca.org/Knowledge-Center/Research/Documents/ITAF-3rd-Edition_fmk_Eng_1014.pdf.
36. ISACA 2013, 1202 Risk Assessment in Planning.
37. ISACA 2013, p. 25.
38. Office of the Auditor General WA 2014, ‘Cloud computing management’, https://audit.wa.gov.au/reports-and-publications/
reports/information-systems-audit-report-2014/cloud-computing-management/.
39. Australian Government Department of Finance 2014, Australian Government Cloud Computing Policy: Smarter ICT
Investment, www.finance.gov.au/sites/default/files/australian-government-cloud-computing-policy-3.pdf.
40. Office of the Auditor General WA 2014.
41. Office of the Auditor General WA 2014.
42. Fra Luca Pacioli was an Italian mathematician who is widely regarded as the ‘Father of Accounting’. His 1494 mathematics
textbook included a detailed description of the double-entry bookkeeping system used by Venetian merchants, which is the
foundation stone of all modern accounting systems.
43. Singleton, T 2007, ‘The COSO model: how IT auditors can use it to evaluate the effectiveness of internal controls information
systems’, Information Systems Control Journal, vol. 6.
44. ISACA n.d., ‘COBIT case studies by industry’, www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-Case-Studies.aspx.
45. Lozano, AL 2014, ‘Mapping COBIT 5 with IT governance, risk and compliance at Ecopetrol’, COBIT® Focus, vol. 3, July,
www.isaca.org/Knowledge-Center/cobit/cobit-focus/Documents/COBIT-Focus-Volume-3-2014_nlt_Eng_0714.pdf.
46. Bierstaker, J, Janvrin, D & Jordan Lowe, D, ‘What factors influence auditors’ use of computer-assisted audit techniques?’
Advances in Accounting, vol. 30, no. 1, pp. 67–74.
47. Benford was a physicist who observed this characteristic and tested it across a wide range of different types of data. Nigrini
first applied it to accounting data.
48. Nigrini, MJ 1999, ‘I’ve got your number’, Journal of Accountancy, May, www.journalofaccountancy.com.
49. Leung, P, Coram, P & Cooper, BJ 2007, Modern auditing and assurance services, 4th edn, John Wiley & Sons Australia Ltd,
Brisbane, pp. 296–98. Reproduced with permission.
50. New Zealand TVOne News, 19 April 2007.
51. ‘Police lose memory stick with top secret terrorist information’ 2008, Daily Mail, 15 September, www.dailymail.co.uk.

ACKNOWLEDGEMENTS
Auditing Standard No. 5 quotes: © Public Company Accounting Oversight Board.
Photo: © nyul / iStockphoto.

632 PART 4 Systems issues

CHAPTER 14

Ethics and cybercrime

LEA RNIN G OBJE CTIVE S

After studying this chapter, you should be able to:

14.1 discuss the way ethical theories provide a basis for decision making in organisations
14.2 solve an ethical dilemma by applying an ethical decision-making model
14.3 explain and give examples of ethical issues relating to accounting information systems
14.4 discuss and provide examples of cybercrime
14.5 evaluate the impact of fraud on organisations
14.6 describe and evaluate controls that reduce the risk of crimes facilitated by technology
14.7 appraise new trends and issues associated with new technologies.
Introduction
This chapter provides an overview of ethical theories that can help us to make good decisions when
faced with ethical dilemmas. Ethical theories help us to explore and better understand the implications of
a decision rather than just to say it ‘feels right’. Ethical theories help us to be able to justify our choices.
An ethical decision-making model provides guidance on how to navigate difficult and complex issues in
reaching a decision. This chapter provides some examples of ethical issues relating to accounting infor-
mation systems and how these issues can be managed effectively; for example, professional codes of
conduct are a basis of behaviour expected in professions.
After the discussion on ethics, the chapter moves on to the area of cybercrime and ethical issues
associated with technology. We explore the controls required to reduce the risk of crimes facilitated by
technology and finish the chapter by identifying new trends associated with new technologies.

14.1 The importance of ethics

LEARNING OBJECTIVE 14.1 Discuss the way ethical theories provide a basis for decision making in
organisations.
The central question of ethics is: what ought one to do? Ethics is a branch of philosophy. Ethics is central to
the study of all business disciplines, including accounting. All types of business (including not-for-profit) and
government entities need to consider the ethical implications of their actions. Businesses and governments
have control of the world’s resources, and managers make decisions every day that affect those resources and
the lives of millions of people. It is important that those who operate in the business world have an under-
standing of ethical theories and philosophies to help guide their decision making.
Some common sayings include the following.
•• Don’t hurt people.
•• Do no harm.
•• Do unto others as you would have them do unto you.
•• Don’t tell lies.

634 PART 4 Systems issues

These sayings are derivatives of ethical thinking developed by philosophers over centuries. The ancient
Greek philosopher, Epicurus (341–270 BCE), believed that virtue or tranquillity of the soul was based
on pleasure and the absence of pain rather than duty.1 Another ancient Greek philosopher, Socrates
(470–399 BCE), asked the question ‘What ought one to do?’ Socrates believed that only ignorance
stopped people from doing what was right.2 Jean-Paul Sartre (1905–1980) believed that human beings
are free, and that no actions are inherently right or wrong and that we must each choose our own ethical
perspectives.3
Ethics is about making a choice or good decision. Ethics is how we act to make the ‘right’ choice and
produce ‘good’ behaviour. Ethics involves examination of principles, values, duties and norms, consider-
ation of available choices in order to make the decision and strength of character to act in accordance
with that decision.4
Ethical theories are used to help people decide which course of action is best. In business, it is accepted
that there should be certain ethical standards. However, what are those standards and how are they deter-
mined? Is pursuing financial gain and self-interest at the expense of the environment and the community
and with lack of consideration of others acceptable? Should individuals enter into contracts knowing that
they may not be able to meet their commitment? Should organisations pollute the environment because
financially it is not worth installing anti-pollutant equipment? Should individuals shirk their responsi-
bilities at the expense of their workmates? How do we answer such questions?
It seems that, despite technological advances in business and communications, ethics is still a fun-
damental issue to be explored and debated. In fact, due to the business world becoming more globally
focused and the community becoming more educated and aware, the subject of ethics and, in particular,
business ethics, is gaining increasing attention. The changes in people’s value systems over the past few
hundred years have meant that old rules and expectations (e.g. how we deal with corporate governance,
the environment or each other) cannot be relied upon to seek solutions; instead, thoughtful, reasoned
consideration needs to be given to the facts at hand in each circumstance. This means that an under-
standing of ethics is important to anyone in business. To appreciate some of these points of view, it is
necessary to explore the theoretical aspects of ethics. While there are many perspectives and theories
relating to ethics, for the purposes of this chapter we will discuss only some of the consequentialist
theories and non-consequentialist theories.

Consequentialist theories
Consequentialist theories (also called teleological theories) are ethical theories which argue that the
consequences of any action should be the basis for making a judgement about the right decision when
faced with an ethical dilemma. If the action results in a good consequence, then the behaviour is said to
be ethical. This raises two issues.
1. What is a desirable consequence?
2. By whose judgement is the consequence examined?
There are a number of theories in this category, the most notable being utilitarianism. Utilitarianism
was derived from the work of Jeremy Bentham (1748–1832) who defined happiness as ‘utility’. He
espoused the need for individuals to maximise their utility and argued that, if all individuals did so,
this would lead to society’s utility being maximised also. The logic was that society’s utility is the sum
of each individual’s utility. This line of thinking was derived from the doctrine of hedonism (from the
Greek word for pleasure), which argued that happiness is the ultimate goal of human behaviour (psycho-
logical hedonism) and that moral good is identical to happiness (ethical hedonism). Bentham, himself,
did not particularly believe that each individual was only capable of acting in their own self-interest;
rather, in general terms, it was the common good, or the maximisation of human happiness in totality,
that was important. He called this the ‘greatest happiness principle’.5
John Stuart Mill (1806–1873) advanced the theory that the maximisation of an individual’s utility
should not be at the expense of the group or community. He proposed that behaviour should be based
on what provides the greatest good to the greatest number — the idea was to maximise the utility

CHAPTER 14 Ethics and cybercrime 635

of society as a whole rather than that of individuals. Generally, in business, this basic principle fits
nicely with the efficiency theme. That is, it is in the public’s best interest if businesses focus on
profitability, as it will ensure the maximum production from their limited resources. In fact, it is from
this theme that many governments in the developed world promote risk-taking business structures, as
it is through risk taking that entrepreneurial firms generate the wealth that leads to economic pros-
perity for the nation. However, some of the high-profile corporate collapses and scandals in recent
years have led to governments stepping in and increasing regulation, particularly in relation to cor-
porate governance.
The most basic form of utilitarianism is the cost–benefit analysis, where the costs and benefits are
calculated for a particular decision. The outcome should be the decision that provides for the greatest
overall gain. This appears straightforward and easy to apply. However, there are challenges to this
approach. For example, how can we measure the ‘good’? How do we measure ‘happiness’? Does one
person’s extreme happiness override three people’s moderate unhappiness?6
There are two major criticisms of utilitarianism: the rights of individuals are not taken into account
and it does not consider the minority question. As the rights of any one person are not taken into account,
some individuals may suffer great harm, while others may receive only modest benefits. Where the
majority rules, who speaks for the minority or ensures that the minority is heard, and who makes sure
that different opinions are able to be expressed?7

Non-consequentialist theories
The consequentialist theories are about making the decision that will cause the least harm, or looking
at the consequences of the decision (the ends). In contrast, non-consequentialist theories, or deonto­
logical theories, determine the ethics of a decision by looking at the process of the decision (the means).
Deontological theories are concerned with duty and rules.
German philosopher Immanuel Kant (1724–1804) proposed that an action is morally right if it is
motivated by good will that stems from a sense of duty. This is known as Kantianism. But how do you
determine if an act is done in good will? Kant proposed the ‘categorical imperative’ as a general rule
that could be used in any given ethical situation,8 but that some actions were not acceptable (e.g. murder)
even if the action would bring about more happiness than the alternative. Kant believed that there were
two questions that should be asked.
1. Can I rationally ask that everyone act as I propose to act? If not, then it is not ethical to perform that
action.
2. Does my action respect the goals of human beings rather than just my own purpose? If not, then the
action should not be performed.
The first of these maxims is similar to the ‘do unto others as you would have them do unto you’ phil-
osophy. If you took out credit knowing that you could not pay it back, would you be in favour of a uni-
versal law that dictates that this is acceptable practice? If so, logic would suggest that eventually no-one
would extend credit, thus grinding to a halt the cycle of the credit markets. In fact, the global financial
crisis during 2008 was firstly a credit crisis that overflowed into the general business arena and signifi-
cantly impacted on people’s savings, investments and house prices.
The second maxim is that the end does not justify the means or, to put it another way, you should not
take advantage of people to achieve a certain end. Kant’s philosophy is grounded in the notion of respect
for the individual. Hence, the requirement that people should be treated as ends and not as a means to
others’ ends. People themselves are not machinery, capital or commodities at the disposal of others for
their self-interest.
Kant’s philosophy is embedded in duty or obligation and encompasses a dignity or respect for the
individual. So, a business motivated by profits, despite doing respectful things, is acting in a prudent way
and not a moral way. However, critics point out that Kant’s universal obligations do not take into account
particular situations. This is especially relevant in business situations where impartiality is assumed. Busi-
nesses undertake transactions at ‘arm’s length’, give all employees equal opportunity and treat customers

636 PART 4 Systems issues

similarly. However, it is sometimes argued that there is a need to recognise special relationships and
therefore to act with partiality. For example, in business, the concept of supply chain management may
warrant the building of special relationships between suppliers and customers. If supply is restricted, it
is natural for suppliers to favour customers who order regular shipments and always pay on time. In fact,
in some countries (e.g. Japan) loyal and trusting relationships are treasured, and the universal obligation
to treat all customers equally would be seen to disrespect those special relationships. Most people can
accept a business doing favourable deals with their loyal customers, suppliers or employees. Discounts
or favourable terms would be seen as a part of treating them with respect and rewarding them for their
hard work and loyalty. So when does partiality become immoral? Ethical theories provide a framework
to help us answer this question.

Importance of ethics in AIS and accounting

Ethics is very complex. To be able to make an ethical decision, we must adopt a framework (or a
theory) as a starting point. Decisions based on intuition and personal feelings do not always achieve
the best outcome. The accounting profession has suffered setbacks over the years relating to finan-
cial fraud which has not been detected by auditors.9 A well-known type of fraud is the Ponzi scheme,
named after Charles Ponzi. In 1920, Charles Ponzi concocted a scheme where he paid investor returns
from newer investors’ money and kept most of the money for himself, becoming a millionaire. Ponzi
lost $20 million in investors’ money (equivalent to $222 million today) and six banks folded. In
2008, Bernard Madoff was sentenced to 150 years in prison for operating a Ponzi scheme which lost
investors $65 billion.
Insufficient internal control has led to another type of financial fraud involving ‘rogue traders’
in investment banks. In September 2011, a trader at UBS (a Swiss financial bank) was arrested for
losing $2.3 billion of the bank’s money. In 2008, Jerome Kerviel lost €50 billion of money held by
Société Générale in France. In 1995, Nick Leeson, who worked for British investment bank Barings,
lost $1.4 billion on the Singapore International Money Exchange (SIMEX), leading to the collapse of
the bank.
In Australia and globally, according to PwC’s 2014 Global Economic Crime Survey,10 the top three
economic crimes are asset misappropriation, cybercrime and procurement fraud. Over half of the respon-
dents in the survey (57 per cent) reported that they had experienced crime in the previous 24 months (up
from 47 per cent in 2012). Internal fraudsters, often from middle management (65 per cent), were the
main perpetrators. In 2014, 36 per cent of organisations reported that they had suffered losses of over
$1 million in the previous 24 months (up from 16 per cent in 2012). This shows that the cost to organ-
isations where economic crimes occur is immense, involving the cost of the fraud itself as well as associ-
ated costs of, for example, investigation of the fraud, legal fees and management time. Many of these
crimes involved manipulation of accounting information systems to misappropriate funds.

Ethical issues in business

Ethical issues in business are increasing as business becomes globalised and more complex. The Aus-
tralian Securities and Investments Commission (ASIC) 2013–2014 Annual Report11 reveals that during
the period there were 113 investigations and 95 criminal and civil litigation and administrative actions
completed, including 15 criminal proceedings, with eight cases of imprisonment secured. Examples of
cases include former Gunns Limited chairman John Eugene Gay, who was convicted of insider trading
and fined $50 000. Mr Gay was the most senior executive to be convicted of insider trading in Australia.
In another case, Russell Johnson, former sole director of Sonray Capital Markets Pty Ltd (Sonray),
was sentenced to six-and-half-years imprisonment in April 2014. Sonray collapsed in 2010 owing more
than $46 million and, as a result of the investigation, Mr Johnson was charged with multiple offences
including false accounting, theft and deception, and conspiracy to steal.12 Clearly, these are ethical
breaches as well as violations of the law.

CHAPTER 14 Ethics and cybercrime 637

 Often it is whistleblowers who initially bring these cases of misconduct or corruption to the attention
of authorities such as ASIC. A whistleblower is someone who exposes corruption or malpractice, and in
many cases they are abused or harassed for speaking out.13
Professional ethics extend to standards of behaviour in a profession. For example, the code of ethics
for professional accountants is issued by the Accounting Professional and Ethical Standards Board
(APESB). The standards are mandatory for all members of the accounting profession. APESB-issued
standards are consistent with those issued by the International Federation of Accountants (IFAC).

14.2 Ethical decision making

LEARNING OBJECTIVE 14.2 Solve an ethical dilemma by applying an ethical decision-making model.
A framework is needed in which to apply ethical principles. This section discusses the different stages
of ethical decision making and how ethical perspectives can be applied to ethical decision-making scen-
arios. The stages to go through when making an ethical decision are as follows.
1. Identify the facts.
2. Define the issue(s).
3. Identify the principles that can be applied.
4. Identify possible actions and the stakeholders affected by these actions.
5. Compare steps 3 and 4.
6. Select a course of action.
7. Implement the selected course of action.
1. What are the facts?
The first step is to identify the main facts of the case you are dealing with. This can include the identifi-
cation of stakeholders who are involved in the decision, actions leading up to the decision and any other
information relevant to making an informed decision.
2. Define the issue
Based on the facts of the case identified in step 1, what is the ethical issue you are dealing with? What is
the decision you have to make? Note that a case could have more than one ethical issue involved.
3. What principles can be used to solve the issue?
Having identified the ethical issue, what are the theoretical principles or sources of authority for solving
the ethical issue? What theoretical framework should be used to make a ‘good’ decision?
4. What are the alternative courses of action and the stakeholders affected by these actions?
The next step is to identify all the possible alternatives. This step does not select the best alter-
native; rather, the aim of this stage is to be aware of what possibilities exist for resolving the ethical
problem. Do not be restrictive at this point: all possible courses of action should be listed. Also of
interest is how the different courses of action affect the different stakeholders identified in stage 1
of the decision-making process. Therefore, each alternative needs to be evaluated from the perspective
of the different stakeholders.
5. How do the principles match up with the alternative actions?
At the fifth stage, the interest lies in matching up the courses of action with the ethical theory. The fun-
damental question at this point is whether the alternatives are consistent with the theoretical perspectives
identified in step 4.
6. Select the most appropriate action
With the alternatives to the ethical principle mapped, the best alternative needs to be selected based on
the theoretical principles used to analyse the case. What is the justification for your decision?
7. Implement the decision
Having evaluated the alternatives, mapped them against ethical principles and selected the most desir-
able option, the chosen option now needs to be implemented. Afterwards, the person and organisation
may be interested in any feedback from the decision.

638 PART 4 Systems issues

Applying the framework
To help you understand the ethical framework, consider this scenario:14
A job search dilemma
John is in his final semester of university and is anxious about getting a job once he graduates. This is par-
ticularly worrying because the job market for graduates isn’t robust in the current economic climate. John
finds it easy to find and apply for lots of jobs because he can utilise so many online resources such as job
websites (e.g. careerone.com.au and seek.com), social networking sites and mobile phone applications.
John applies for every job that he thinks he may be qualified for, regardless of whether he is really interested
in the job. John receives a call almost immediately about a job that doesn’t really interest him, but he sched-
ules an interview. John performs well in the interview and is offered the position.
Should John accept the offer? If he does, should he continue to look for other jobs?
When reading a case study, it is important not only to understand what the case study is about, but
also to consider what your own experience can add to the analysis. In order to advise John, we will use
the ethical decision-making model to work through the case.
1. Identify the facts. John has been offered a job he isn’t interested in. The stakeholders are John, the
organisation employing John, John’s new manager, the team members John will be working with, the
organisation’s customers, John’s family and friends, and John’s creditors (people or organisations that
John may owe money to, e.g. a bank with which John has a loan or a credit card debt).
2. Define the issue(s). The decision (or dilemma) is whether John should take the job or not. If John
decides to take the job, should he continue to search for other jobs?
3. Identify the principles that can be applied. John could use a consequentialist theory such as utili-
tarianism which argues that John should consider carefully the consequences of his decision. Alterna-
tively, John could use a deontological theory, such as Kant’s theory, to work through his dilemma by
considering whether taking the job is acting through good will and following the rules.
4. Identify possible actions and the stakeholders affected by these actions.
(a) John could take the job and stop looking for another job. (This decision affects all stakeholders:
John, the organisation employing John, John’s new manager, the team members John will be
working with, the organisation’s customers, John’s family and friends, and John’s creditors.)
(b) John could decline the job and keep looking until he finds a job that he is interested in. (This
decision affects the following stakeholders: John, John’s family and friends, and John’s creditors.)
(c) John could take the job and keep looking until he finds a job he is more interested in. (This
decision affects all stakeholders: John, the organisation employing John, John’s new manager,
the team members John will be working with, the organisation’s customers, John’s family and
friends, and John’s creditors.)
5. Compare steps 3 and 4.
Utilitarianism theory
(a) John should consider the potential harm or inconvenience to his potential new employer if he is
a bad fit for the job. If John ignores this, it will result in him looking for another job quite soon
which would inconvenience his new employer and cause John a lot of unhappiness.
(b) If John does not take the job and decides to keep looking, he will have shown a level of self-awareness
that others are likely to respect. If John has financial obligations this may be a difficult choice.
(c) John should consider the potential harm or inconvenience to his potential new employer (e.g. his
manager, team members and customers) if he accepts the job and continues to look for another
job. Considerations include the amount of money it costs an organisation to recruit employees,
induct and train new employees, and develop teams and their relationships with customers and
other teams in the organisation. On the other hand, if John has financial obligations he would need
to take the job to pay his bills. John’s career will not benefit if he is perceived to be a job hopper
and unable to commit to a role. It may also affect John’s confidence and self-esteem if he makes
an inappropriate career choice at this stage of his career.

CHAPTER 14 Ethics and cybercrime 639

 Deontological theory
(a) John may have financial obligations, which means he believes he has to take the first job that comes
along to satisfy these obligations. John could take the view that he could learn something from the job
and see where it takes him. John should take the job so that his family and friends will not be affected by
him being out of work. This will affect all stakeholders, particularly family and friends and creditors.
(b) John may decline the job because it is the right thing to do — because he is not really interested
in the position.
(c) John could take the job and keep looking until he finds the right job or the right fit. This is the
right thing to do if John has financial obligations and needs the work.
6. Select a course of action.
Utilitarianism theory
If John works through the consequences of his choices, John would choose to not take the job and
keep looking for a job that he is interested in. If John takes the job and then leaves quickly, he is
likely to cause a great deal of harm to both his employer and himself.
Deontological theory
John should decline the job because it is the right thing to do. If he does take the job, he is being
dishonest to his employer and to himself.
7. Implement the selected course of action. John should decline the job and keep looking for a job he is
interested in by targeting his job search better.
It is important to note that this is just one way of working through a case. There are many different
perspectives and you have to make assumptions. The important point is that you can work through and
justify your response to a particular ethical dilemma.

14.3 Ethical issues in accounting

information systems
LEARNING OBJECTIVE 14.3 Explain and give examples of ethical issues relating to accounting
information systems.
Think of some of the recent events you may have experienced as a customer — for example, visiting the
doctor or consulting an accountant — that require you to divulge personal information. Implicit in this is
the expectation that the doctor or accountant will use the information ethically (and, in fact, the codes of
ethics of their respective professional associations require them to maintain confidentiality). For example,
you would not expect your family doctor to discuss details of your ailments and problems at the next
dinner party the doctor attends. Likewise, you would expect your accountant to keep details of your finan-
cial position and wealth to themselves and not discuss it with other clients. In each of these cases there
is an expectation that the professional acquiring the information from the client will use it only for the
purpose for which it has been gathered. Commercial enterprises face similar ethical expectations when
dealing with their customers. From an organisation’s perspective, the issue of ethics is one that never dis-
appears. In this era of e-commerce and big data, the ethical issues become even more complex.

Customer protection and privacy

Privacy and trust are two big issues for the people and organisations that interact with an organisation.
In many countries there is no obligation for organisations to report data breaches, although this is
changing. In Australia, the Privacy Amendment (Privacy Alerts) Bill 2013 to establish a framework for
the mandatory notification by regulated entities of serious data breaches to the Australian Information
Commissioner and to affected individuals lapsed on prorogation of the 43rd Parliament. A private
members bill, the Privacy Amendment (Privacy Alerts) Bill 2014 was stalled in the Senate because of the
lack of government support. The current government has committed to passing mandatory data breach
legislation by the end of 2015.15 In the PWC Global State of Information Security Survey 2015, the total

640 PART 4 Systems issues

number of security incidents detected by respondents climbed to 42.8 million during the period surveyed
(27 March 2014 to 25 May 2014), an increase of 48 per cent from 2013. What is most troubling is that
many organisations are unaware of attacks, while some do not report attacks for strategic reasons or
because the attack is being investigated as a matter of national security.16 It may appear that passing on
information about people is a victimless crime, but that is far from the truth. Consider the data breaches
and the implications for the organisations and customers, described in AIS Focus 14.1.

AIS FOCUS 14.1

Data breaches
AshleyMadison.com specialises in extramarital affairs (a dating site?). Its tagline is ‘Life is short, have an
affair’. In 2015 AshleyMadison data was ‘stolen’ from Avid Life Media (ALM), the parent company of Ashley-
Madison.com and two other websites, Established Men and Cougar Life, and posted online. What appears
to be different about this data breach is an apparent moral dimension. Potentially 37 million users (adulterers)
may have been affected, although the number of users remains unconfirmed. The website promised privacy
and security of users’ most intimate details. The hackers, calling themselves the Impact Team, ordered ALM
to take down AshleyMadison and Established Men websites or they would release the details of the hacked
customers. What appears to be particularly problematic from the hackers’ perspective was that ALM offered
a full delete service for $19 that obviously did not delete personal data such as credit card details and real
names and addresses, and therefore was ‘a complete lie’.17,18
In a related data breach, AdultFriendFinder, a website for dating and casual sexual relationships, had
3.9 million customer records hacked, including users’ sexual preferences, email addresses, dates of
birth and, in some cases, whether they were looking to cheat on their spouses.19
One of the largest security breaches over the internet was the theft of data (names, addresses, email
addresses, birth dates, passwords, security questions and credit card details) of more than 77 million
customers of the Sony PlayStation Network in April and May 2011. Sony discovered the breach seven
days before it notified its customers.
How did this happen? It may be that in getting their products to market quickly, software errors occurred
that provided hackers with a way to steal customer information.20 It was reported that Sony had insufficient
security in place for its systems. It did not have a firewall in place, nor did it have a system in place to patch
security holes in its software, resulting in outdated security.21 The Sony PlayStation Network is an example of
cloud computing that has shown how easy it can be for hackers to compromise security. At an average cost
of US$318 per account, the cost to Sony’s business was estimated to be US$24.5 billion.22

Privacy is both a legal and an ethical issue. Privacy can mean different things to different people in
different contexts. Therefore, privacy is complex and there is no one single definition of privacy that
defines all perceptions and behaviours across a range of contexts.23 A definition of privacy preceding the
internet that is still relevant today is: ‘the claim of individuals, groups, or institutions to determine for
themselves when, how, and to what extent information about them is communicated to others’.24 Personal
information has a specific definition in legislation. In Australia, the Privacy Amendment (Enhancing Pri-
vacy Protection) Act 2012 (Cth) (Amending Act),25 defines personal information as information or an
opinion about an identified individual, or an individual who is reasonably identifiable:
(a) whether the information or opinion is true or not; and
(b) whether the information or opinion is recorded in a material form or not.26
This definition includes data or information about an individual which, combined with other infor-
mation (that may or may not be held by the same entity), identifies the individual or provides a way
to reasonably identify the individual. The Explanatory Memorandum to the Privacy Amendment
(Enhancing Privacy Protection) Bill 2012 (Cth) (Explanatory Memorandum) explains that context and
circumstances should be taken into account including the cost, difficulty, practicality and likelihood that
the information will be linked.27
In New Zealand, the Privacy Act 1993 defines personal information as information about identifiable
living people.28

CHAPTER 14 Ethics and cybercrime 641

 The Privacy Act 1988 regulates how personal information is handled about individuals. This includes
the collection, use, storage and disclosure of personal information, and access to and correction of that
information.29
In May 2014 the Luxembourg-based Court of Justice of the European Union (EU) set a precedent
for ‘the right to be forgotten’ which means that you have a right for links to certain data about you on
the internet to be removed. The case concerned a Spaniard, Mario Costeja Gonzalez, who had financial
difficulties 16 years in the past, but every time someone googled his name this piece of information
appeared. Mr Gonzalez argued that the link to this piece of information should be removed because
it had an impact on his reputation, and the court agreed.30 The data still exists on the internet, but the
search results through a search engine, specifically Google in this case, will not return that specific infor-
mation. At the time of writing, the EU was finalising legislation that would enshrine this right into law.31
An AIS captures, verifies, stores, sorts and reports data relating to an organisation’s activities, including
customer data. Electronic AISs allow organisations to gather much more information about people than
was possible in a more traditional environment. Indeed, the details of any interaction with the AIS can be
captured and this information can then be used in many ways.
The person interacting with the AIS is not necessarily aware of what information is being captured or
how it will be used. This raises some ethical concerns for those who design and use information systems.
The organisation has both ethical and legal responsibilities to respect people’s right to privacy and this
affects how the organisation can capture and use information.
E-commerce and mobile commerce offer efficient transactions, customer convenience (the ability to
shop whenever and from wherever they like) and the potential to reach to a broader marketplace. A busi-
ness can also capture extensive information about visitors to its website. When users visit a website they
leave behind electronic footprints, which enable the site owner to identify what site they came from,
what they did while on the site and where they went after viewing the site. Based on these data, viewers
can be profiled and advertising can be targeted to meet user interests, needs and preferences.
Another issue stemming from e-commerce is what happens to the data about consumers after it has
been gathered, particularly in the era of big data. Data is collected every time we shop, use public trans-
port or a toll road, access government services and when we work out using a smart phone app or a
fitness device. That is, data is collected about individuals during almost everything we do. The collec-
tion of data can reveal sensitive information about us including our shopping preferences, friends, what
disease we may have and our fitness regime.32 It is still unclear as to how organisations are dealing with
the ethical and social issues relating to big data and data analytics.33
Organisations can undertake data mining and customer profiling, often without the user being aware
of it: there is often no explicit seeking of consent to the gathering and use of the data collected. Con-
sumer advocates see this as an invasion of privacy that can lead to a lack of trust on the part of the con-
sumer. This lack of trust has big implications for the future development of e-commerce. Additionally,
the customer profiling may not necessarily generate an accurate picture of the customer.
One company that has been particularly successful in offering products that assist organisations in mon-
itoring and responding to usage of their websites is DoubleClick, owned by Google.34 DoubleClick makes
extensive use of cookies — small files stored on a computer’s hard drive that keep a record of websites
viewed, viewing preferences, user profiles and so on. Developed ostensibly to allow websites to display in the
most user-friendly format, based on the operating system used, browser type and so on, cookies can also help
organisations to gather data about the people that access their websites. For example, a cookie can:
•• ensure the browser does not display ads the user has already seen
•• ensure ads are shown in a particular sequence
•• track whether a user has visited the site before
•• track the previous and next sites the user visits.
As smartphones have become more prevalent, DoubleClick has introduced a mobile ad delivery ser-
vice for organisations to track mobile websites.35 Through the tracking of IP addresses, as well as gath-
ering the details of users as they log on and purchase from internet-based store interfaces, companies are

642 PART 4 Systems issues

able to build up relatively comprehensive profiles of a customer, including interests, purchasing patterns
and viewing patterns on the internet.36 This information can then be used to target online advertise-
ments and banner displays that appear when the user accesses a particular page. Through these technol-
ogies, DoubleClick offers a way for organisations to target online advertising to specific customers, thus
increasing the relevance of banner advertising and adding to revenue through increased sales.
It is clear that this practice raises some ethical issues, particularly privacy issues, which directly affect
the customers of an organisation. If a consumer makes a purchase through an online store or accesses a
website, are they aware that information is being gathered about them and a profile being developed that
could be used in future marketing efforts? If not, then is it right for the organisation to gather this infor-
mation? These are very real issues for information systems professionals that extend to the AIS domain,
especially as the development of electronic commerce sees the AIS playing a major role in supporting
online consumer activities.
Before moving on to look at security of data, read AIS Focus 14.2, which describes radio frequency
identification (RFID) and how it is being used for asset tracking in a number of different industries and
the privacy and ethical issues that potentially arise.

AIS FOCUS 14.2

RFID: asset tracking capabilities and more

RFID is becoming entrenched in supply chains across retail, logistics, defence, healthcare and pack-
aging, amongst others. The following examples show how pervasive this technology has become for
tracking assets and even people.
Law enforcement organisations are required to carefully manage and track assets such as firearms
and vehicles as well as evidence for cases. The Sheriff’s Office in Val Verde County, Texas, is piloting
RFID for monitoring officers’ equipment and vehicles.37 The Baker Police Department uses RFID to track
assets and manage items of evidence. The shelf ID number for each piece of evidence is listed in the
information system. When an officer walks into the evidence vault, the reader captures that individual’s
ID number on his/her RFID-enabled badge. As he/she leaves with a piece of evidence, that ID is cap-
tured as well, and this again occurs when he/she returns it.38
Manufacturing organisations track a variety of assets, some as small as work-related tools, some as
large as assets like shipments of car parts. The consequences of not receiving parts on time or losing
assets through theft can be significant for the organisation’s workflow and reputation.39 Traditionally,
RFID was associated with large manufacturers with complex supply chains. However, as RFID
technology becomes more affordable, smaller manufacturers are able to use RFID to streamline their
workflow. Stoll & Co., a small watch-repair firm with 62 employees, based in Dayton, Ohio, uses RFID
to track watches from receiving through to repairs. Prior to implementing RFID, watches were often
misplaced and a lot of time was wasted looking for the correct watch. This is not surprising when
you consider that each watch might go through as many as 15 different people as it is disassembled,
cleaned, repaired, lubricated, timed, pressure checked and reassembled.40
Education is another area where RFID is being used to track students, from junior school through to
college students.41 In Casamassima, a city in Italy’s Apulia region, RFID is used in five public schools
to identify children as they arrive, and to automate the ordering and payment of each child’s lunch. This
has replaced paper food stamps that had to be handed in each day and checked. The manual process
was time consuming and the catering company did not know how many meals to prepare. When stu-
dents arrive at school each morning, the reader at the building’s entrance captures each child’s back-
pack tag ID and forwards that data to the Kubos software residing on the school’s database, via a Wi-Fi
connection. The software identifies how many students will require each type of meal (based on dietary
requirements) and places that order with the caterer. It also automatically deducts the lunch cost from
each child’s account. The catering company can then prepare the exact number of meals required for
that day.42 Northern Arizona University uses RFID to track attendance at larger classes on campus. In
2012, a student in Texas refused to wear a student ID card that contained an RFID chip and was subse-
quently suspended from school. However, after a court case and the school discontinuing inserting an
RFID chip in each student’s ID card, the student returned to school.43 In a blog, Against RFID in schools,

(continued)

CHAPTER 14 Ethics and cybercrime 643

 AIS FOCUS 14.2 (continued)

the latest legislation on and adoption of RFID in schools is explained.44 On the one hand, RFID can pro-
vide a number of benefits for tracking children, particularly relating to safety. On the other hand, there
are privacy tradeoffs that may be unacceptable to both students and their parents.
At Connecticut’s Stamford Hospital, real-time location system technology is used to display patient- and
personnel-related data on a monitor installed within each patient’s room, based on a signal transmitted by a staff
member’s ID badge. The technology identifies a staff member by their tag and displays their name and title on a
monitor for the patient. At the same time, patient information such as vital signs, medical tests and results, and
care requirements are displayed on the screen. The purpose is to provide workers with real-time information.45
The main issues with RFID are privacy and security. Organisations are clearly interested in where
their products are, but more importantly they are interested in where their products go and how they are
used. What does this mean? It means that RFID can keep track of you, what you buy, where you shop,
what you don’t buy and how products are used. Some workers in Sweden have had RFID microchips
inserted into their hands so that they can open doors, operate photocopiers and make future payments
with a wave of their hands. Following on from this, individuals can log their fitness activities and nutrition,
amongst other data.46 RFID has the potential to provide much more information about us — everywhere
we go, everything we purchase and everything we do, from the car we drive to where we live, to how much
salary we earn, to what we like to eat and how much exercise we do. This may be great for catching crimi-
nals, but do you really want all that information available to anyone who can pay for it?

For businesses, information about the habits of people can prove extremely profitable. However, with
this approach come the ethical issues of privacy and freedom. Your opinion on these issues will very
much depend on how you perceive the threat to privacy from technology. For customers, incidences
where personal data are disclosed do the most damage to their image of a company. This can occur by
accident or through unauthorised hacking into the system like the examples in AIS Focus 14.1.
Security
Data and the programs that maintain or use data must be kept secure. One reason is to respect the pri-
vacy rights of individuals. Measures need to be in place to ensure that data cannot be accessed by unau-
thorised employees or copied or used for illegitimate purposes. Well-defined user access rights and user
activity logs can be ways of working towards such aims.
Another aspect to consider is the protection of the quality of the data; that is, to make sure that the
data are accurate. Customers have the right to view data that an organisation holds about them to make
sure that they are correct, and to demand that any errors be corrected (see Australian Privacy Principles
Part 5 — Access to, and correction of, personal information in figure 14.1).
Consent
Information about users of an AIS can be gathered:
•• without the consent of the individual (though this may be illegal and/or unethical)
•• with the express (informed) consent of the individual
•• with the implied consent of the individual.
There is a big difference among these three scenarios. A common concern is whether it is ethical to gather
data about someone without his or her knowledge or consent. Some would say that such acts are tantamount
to electronic espionage and constitute a violation of a person’s basic right to privacy. Gathering information
without the person’s consent would appear to be prohibited under the Australian Privacy Act 1988 (Cwth),
which makes distinctions between express consent and implied consent. Implied consent refers to the indi-
vidual consenting to the information gathering through their subsequent actions. For example, if you complete
a page on a website that asks for your personal details and you click the ‘next’ button to proceed to the next
screen, your actions imply that you agree to forward this information on to the website owner. At no stage
were you asked for an express statement of consent. Express consent would occur where the information is
entered into the fields on the screen and then, as you click on the ‘next’ button, a box appears asking if you
wish to proceed and informing you that if you do proceed your details will be gathered by the website owner.

644 PART 4 Systems issues

 There is a big difference between express and implied consent. Some may argue that, by agreeing to use a
website and entering information, you are giving consent for that information to be gathered. Others would
argue that the only form of true consent is that which is expressly obtained from the subject of the information.
Privacy laws and standards
Privacy laws exist in both Australia and New Zealand. One such example is the Australian Privacy Act 1988
(Cth),47 which is a piece of federal legislation enacted to create standards for the gathering, collection and use
of personal information. The Privacy Act contains 13 Australian Privacy Principles (APPs) that apply to the
handling of personal information by most Australian and Norfolk Island Government agencies and some pri-
vate sector organisations. The Privacy Act also includes credit reporting provisions that apply to the handling
of credit-related personal information that credit providers are permitted to disclose to credit reporting bodies
for inclusion on individuals’ credit reports. The APPs came into force on 12 March 2014, replacing the pre-
vious Information Privacy Principles and National Privacy Principles (NPPs).48 The APPs are in five parts:
Part 1 sets out principles that require APP entities to consider the privacy of personal information,
including ensuring that APP entities manage personal information in an open and transparent way.
Part 2 sets out principles that deal with the collection of personal information including unsolicited per-
sonal information.
Part 3 sets out principles about how APP entities deal with personal information and government-
related identifiers. The part includes principles about the use and disclosure of personal information and
those identifiers.
Part 4 sets out principles that deal with the integrity of personal information. The part includes prin-
ciples about the quality and security of personal information.
Part 5 sets out principles that deal with requests for access to, and the correction of, personal
information.49
The Australian Privacy Principles are summarised in figure 14.1. Note that the full explanation
should be reviewed for exceptions and detailed descriptions.

APP Description Summary

Part 1 Consideration of
personal information
privacy
1 Open and transparent The object of this principle is to ensure that APP entities manage personal
management of information in an open and transparent way.
personal information An APP entity must have a clearly expressed and up-to-date policy (the APP privacy
policy) about the management of personal information by the entity.
2 Anonymity and Individuals must have the option of not identifying themselves, or of using a
pseudonymity pseudonym, when dealing with an APP entity in relation to a particular matter.
Part 2 Collection of personal
information
3 Collection of solicited If an APP entity is an agency, the entity must not collect personal information (other
personal information than sensitive information) unless the information is reasonably necessary for, or
directly related to, one or more of the entity’s functions or activities. An APP entity
must collect personal information only by lawful and fair means.
4 Dealing with unsolicited If an APP entity receives personal information; and
personal information the entity did not solicit the information;
the entity must, within a reasonable period after receiving the information, determine
whether or not the entity could have collected the information under Australian
Privacy Principle 3 if the entity had solicited the information.

FIGURE 14.1 Australian Privacy Principles, from the Privacy Act 1988 (Cth), Schedule 1

(continued)

CHAPTER 14 Ethics and cybercrime 645

FIGURE 14.1 (continued)

APP Description Summary

5 Notification of the At or before the time or, if that is not practicable, as soon as practicable after, an
collection of personal APP entity collects personal information about an individual, the entity must take
information such steps (if any) as are reasonable in the circumstances:
• to notify the individual of such matters referred to in subclause 5.2 as are
reasonable in the circumstances; or
• to otherwise ensure that the individual is aware of any such matters.

Part 3 Dealing with personal

information

6 Use or disclosure of If an APP entity holds personal information about an individual that was collected
personal information for a particular purpose (the primary purpose), the entity must not use or disclose
the information for another purpose (the secondary purpose) unless:
• the individual has consented to the use or disclosure of the information; or
• subclause 6.2 or 6.3 applies in relation to the use or disclosure of the information.

7 Direct marketing If an organisation holds personal information about an individual, the organisation
must not use or disclose the information for the purpose of direct marketing.

8 Cross-border disclosure Before an APP entity discloses personal information about an individual to a person
of personal information (the overseas recipient):
• who is not in Australia or an external Territory; and
• who is not the entity or the individual;
the entity must take such steps as are reasonable in the circumstances to ensure
that the overseas recipient does not breach the Australian Privacy Principles (other
than Australian Privacy Principle 1) in relation to the information.

9 Adoption, use An organisation must not adopt a government-related identifier of an individual as

or disclosure of its own identifier of the individual unless:
government-related • the adoption of the government-related identifier is required or authorised by or
identifiers under an Australian law or a court/tribunal order; or
• subclause 9.3 applies in relation to the adoption.

Part 4 Integrity of personal

information

10 Quality of personal An APP entity must take such steps (if any) as are reasonable in the circumstances
information to ensure that the personal information that the entity collects is accurate, up-to-
date and complete.

11 Security of personal If an APP entity holds personal information, the entity must take such steps as are
information reasonable in the circumstances to protect the information:
• from misuse, interference and loss; and
• from unauthorised access, modification or disclosure.

Part 5 Access to, and

correction of, personal
information

12 Access to personal If an APP entity holds personal information about an individual, the entity must, on
information request by the individual, give the individual access to the information.

13 Correction of personal If an APP entity holds personal information about an individual; and either:
information • the entity is satisfied that, having regard to a purpose for which the information
is held, the information is inaccurate, out of date, incomplete, irrelevant or
misleading; or
• the individual requests the entity to correct the information;
the entity must take such steps (if any) as are reasonable in the circumstances to
correct that information to ensure that, having regard to the purpose for which it is
held, the information is accurate, up to date, complete, relevant and not misleading.

646 PART 4 Systems issues

 The New Zealand Privacy Act 1993 has 12 privacy principles. Principles 1–4 govern the collection
of personal information. This includes the reasons why personal information may be collected, where it
may be collected from, and how it may be collected. Principle 5 governs the way personal information
is stored. It is designed to protect personal information from unauthorised use or disclosure. Principle 6
gives individuals the right to access information about themselves. Principle 7 gives individuals the right
to correct information about themselves. Principles 8–11 place restrictions on how people and organ-
isations can use or disclose personal information. This includes ensuring that information is accurate and
up to date, and that it is not improperly disclosed. Principle 12 governs how ‘unique identifiers’, such
as Inland Revenue Department (IRD) numbers, bank client numbers, and driver’s licence and passport
numbers, can be used.50
The principles apply to government departments, companies of all sizes, religious groups, schools and
clubs, with some exceptions.51
Many consumers provide their information without thinking about how that information will be used.
Social media, personal identification scanning (e.g. in pubs and clubs), completing online forms, shop-
ping and banking online, as well as agreeing to marketing surveys, all involve collecting personal data
about you. Loyalty cards, where cardholders earn points that may be credited towards rewards, special
offers or discounts, collect valuable personal data.
The Australian Privacy Principle (APP) 1.3 requires an APP entity to have a clearly expressed and
up-to-date APP privacy policy describing how it manages personal information. The APP privacy policy
of the APP entity must contain the following information:
a. the kinds of personal information that the entity collects and holds;
b. how the entity collects and holds personal information;
c. the purposes for which the entity collects, holds, uses and discloses personal information;
d. how an individual may access personal information about the individual that is held by the entity and
seek the correction of such information;
e. how an individual may complain about a breach of the Australian Privacy Principles, or
a registered APP code (if any) that binds the entity, and how the entity will deal with such a
complaint;
f. whether the entity is likely to disclose personal information to overseas recipients;
g. if the entity is likely to disclose personal information to overseas recipients — the countries in
which such recipients are likely to be located if it is practicable to specify those countries in the
policy.52
Guidelines for developing a privacy policy that complies with the APPs are available, including check-
lists.53 Consumers, for the most part, do not read the privacy statement or terms and conditions on an
organisation’s website. Using Woolworths as an example, the privacy policy states in part that ‘If you
wish to complain about a breach of the privacy rules that bind us, you may contact our Privacy Officer at
one of the above contact points. We may ask you to put your complaint in writing and to provide details
about it.54
The Office of the Australian Privacy Information Commissioner (OAIC) has the power to inves-
tigate complaints about data breaches that comprise an individual’s personal information. In May
2015 Woolworths accidently sent out emails to over 1000 customers with an Excel spreadsheet and
links to 7941 gift vouchers worth a total of $1 308 505. Individuals could redeem the vouchers
immediately and begin shopping, which some did before Woolworths cancelled the gift vouchers.
This caused more customer distress because some genuine customers tried to use their vouchers and
became embarrassed when they were no longer accepted. The spreadsheet included names and email
addresses of customers.55 The OAIC investigated the breach and found that Woolworths dealt with
the breach appropriately.56
New Zealand supermarket chain Progressive Enterprises Ltd (PEL), owner of Foodtown and
Woolworths, provides one section on privacy on their website, which does not refer to their loyalty
program (called Onecard): ‘We may hold personal information submitted to us by you through your

CHAPTER 14 Ethics and cybercrime 647

use of the Site. You have the right to access and correct your personal information under the Privacy
Act 1993.’57
However on the Onecard website, the privacy section is more comprehensive. Section 3 states:58
3. By applying for and using your Onecard, you agree that we may collect, store and use information
from your application and information on how you use your Onecard, what you buy in our stores
and other information you provide to us, to:
a. Send you any Onecard rewards vouchers you may be entitled to;
b. Understand Onecard members’ shopping habits;
c. Contact you by mail, phone and, if you consent, email or text/SMS:
   i. in relation to any special offers, discounts, promotions, products and/or services offered by us
or other related companies in our group, that may be of interest to you and your family; and
ii.  for research purposes related to your supermarket shopping and other marketing and
promotional purposes.

In Australia, Communications Alliance took over responsibility for industry codes and core res-
ponsibilities of the Internet Industry Association (IIA) under an agreement signed on 24 March
2014. Communications Alliance is the leading body representing Australia’s internet industries and
is dedicated to delivering the ongoing leadership and support needed to collectively drive the Digital
Economy forward.59 According to their website, Communications Alliance has a leadership role in
facilitating industry-based solutions to sectoral issues and is taking steps to bring to fruition the
broadband and digital era, including leading the industry’s involvement in the National Broadband
Network implementation.60

Access to technology
An additional issue for businesses and their customers is their ability to access information and com-
munications technology (ICT), particularly as organisations become more entrenched in the e-commerce
and mobile commerce environment. Access to computer technology can vary depending on socio­
economic conditions and geographic location.
The digital divide is a term that is used to describe the difference in access between those who
have access to ICT and those who do not. The Internet of Everything means that everything is online
and, as of 2015, 12 billion devices are connected to the internet and this number is expected to rise
to 20 billion by 2020. The Networked Readiness Index 2015 shows that there is a clear link between
advanced economies and their ability to leverage ICT and poorly performing economies which have less
access to ICT.61
The International Telecommunication Union (ITU), the United Nations specialised agency
for information and communication technologies (ICTs), released statistics which show that,
between 2000 and 2015, internet penetration increased almost sevenfold from 6.5 per cent to
43 per cent of the global population. The proportion of households with internet access at home
advanced from 18 per cent in 2005 to 46 per cent in 2015. ITU figures also indicate that four billion
people in the developing world remain offline. Of the nearly one billion people living in the Least
Developing Countries (LDCs), 851 million do not use the internet. Mobile broadband is the most
dynamic market segment, with mobile broadband penetration reaching 47 per cent of the global
population in 2015, a 12-fold increase on 2007 figures. In 2015, 69 per cent of the global popu-
lation will be covered by 3G mobile broadband, up from 45 per cent in 2011. There is also rapid
expansion of 3G mobile broadband into rural areas, and the ITU estimates that 29 per cent of the
3.4 billion people worldwide living in rural areas will be covered by 3G mobile broadband by the
end of 2015. Among the four billion people living in urban areas, 89 per cent will have access to 3G
mobile broadband.62
The most recent statistics available from Internet World Stats show that as of 31 December 2014 there
are still disparities between regions (see figure 14.2).63

648 PART 4 Systems issues

 WORLD INTERNET USAGE AND POPULATION STATISTICS
31 December 2014 – Mid-year update

Internet Internet Penetration

Population users users (% Growth Users %
World regions (2015 est.) Dec. 31 2000 latest data population) 2000–2015 of table

Africa 1  158  353  014 4  514  400 318  633  889 27.5 % 6  958.2 % 10.3 %

Asia 4  032  654  624 114  304  000 1  405  121  036 34.8 % 1  129.3 % 45.6 %

Europe 827  566  464 105  096  093 582  441  059 70.4 % 454.2 % 18.9 %

Middle East 236  137  235 3  284  800 113  609  510 48.1 % 3  358.6 % 3.7 %

North America 357  172  209 108  096  800 310  322  257 86.9 % 187.1 % 10.1 %

Latin America/Caribbean 615  583  127 18  068  919 322  422  164 52.4 % 1  684.4 % 10.5 %

Oceania/Australia 37  157  120 7  620  480 26  789  942 72.1 % 251.6 % 0.9 %

WORLD TOTAL 7  264  623  793 360  985  492 3  079  339  857 42.4 % 753.0 % 100.0 %

FIGURE 14.2 World internet usage and population statistics, www.internetworldstats.com/stats.htm.

In Australia, the national broadband network (NBN) is being rolled out across the country. According
to the NBN website:
The aim [of the NBN] is to enable access to fast, reliable and affordable phone and internet services,
from a range of providers. The NBN network is designed to enable lifestyle enhancements including
health, education, well-being, sustainability and wealth. We are committed to closing the digital divide
by providing access to a minimum level of broadband services to homes and businesses across Australia.
Due to the nature and size of our country, we plan to use a mix of technologies to deliver the NBN net-
work, using the best fit solution for each area.64
Neither the NBN nor the Australian government make any claims about speed, technology or specific
time frames, although the website acknowledges that the NBN will be important for Australia’s digital
future.
The New Zealand Government has undertaken an NZ$2 billion investment on behalf of all New Zea-
landers in two major initiatives that will deliver faster, better internet: the Ultra-Fast Broadband (UFB)
Initiative and the Rural Broadband Initiative (RBI). These two programs will bring the benefits of
improved internet connectivity to 97.8 per cent of New Zealanders, opening up a huge range of busi-
ness, educational, community and other opportunities. It is estimated that by 2020, 75 per cent of
New Zealanders will be able to access the internet using UFB, and all schools, hospitals and 90 per cent
of businesses will be connected by 2015.65

14.4 Cybercrime
LEARNING OBJECTIVE 14.4 Discuss and provide examples of cybercrime.
Cybercrime and fraud are described in this section and the next. It is important to recognise that tech-
nology is advancing faster than the legislation can keep pace with it. According to the Australian Cyber-
crime Online Reporting Network (ACORN), cybercrimes are:
• d irected at computers or other devices (for example, hacking), and
• where computers or other devices are integral to the offence (for example, online fraud, identity theft
and the distribution of child exploitation material).66

CHAPTER 14 Ethics and cybercrime 649

 The examples of cybercrime and fraud in this chapter are by no means exhaustive. The discussion
concludes with some strategies for reducing the exposure to cybercrime and fraud, with many of these
relating back to the ethics material that was covered earlier in the chapter.
The term ‘cybercrime’ is often used interchangeably with terms such as computer crime, computer-related
crime, e-crime, high-tech crime, cyber fraud and internet crime. The types of cybercrime include hacking,
online scams and fraud, identity theft, attacks on computer systems and illegal or prohibited online content.67
The cost of cybercrime is not easy to calculate as much of it either goes unreported or is self-reported.
The Australian Cybercrime Online Reporting Network estimated that self-reporting victims of
cybercrime suffered a financial loss of more than $234 million in the first quarter of 2015.68 The
Ponemon Institute, on behalf of HP Enterprise Security, reports estimates of the costs of cybercrime each
year. In the fifth Cost of Cyber Crime Study in 2014, a global study of US-based companies spanning
seven nations, found that over the course of a year the average cost of cybercrime for companies in the
United States rose by more than 9 per cent to US$12.7 million. This was up from US$11.6 million in
the 2013 study. In addition, the average time to resolve a cyber attack rose from 32 days in 2013 to
45 days in 2014.69,70 In the Australian context, the Australian Crime Commission estimates that cyber-
crime costs the country more than $1 billion each year, and small to medium enterprises (SMEs) are
more at risk than large organisations.71 The Ponemon study also found that malicious insiders, malware,
viruses, worms, Trojans and botnets were the most common attacks on SMEs. Malicious code, phishing
and social engineering were more common in larger organisations. This is serious, and all organisations
and SMEs need to be aware of cybercrime and how to mitigate its effects.

Malware: viruses, worms, Trojans, bots

Malicious code designed to damage, disrupt or steal data, or disrupt computer systems and networks is
known as malware. The most common types of malware are viruses, worms, Trojans and bots.
Viruses and worms can range from mildly annoying to denial of service (DoS) attacks. Viruses are
attached to an executable file (a file that the computer can run). This means that a computer can have a
virus, but the user may not be aware of it until they open or run the program. The host program in most
cases continues to run, but the virus may overwrite the host program and infect other programs. The
virus is spread by attaching itself to email attachments and documents.72 Worms are stand-alone soft-
ware that do not need another program or human to replicate. For worms to spread they exploit a vul-
nerability of the systems or use social engineering (discussed below) to trick users into executing them.
Trojans are particularly dangerous because the software looks genuine. Once the Trojan is activated,
it can cause a great deal of damage, ranging from annoying users with pop-up software or changing the
desktop through to damaging the host. This damage can include deleting files, spreading viruses and
stealing data. Trojans can also create back doors for malicious users to gain access to host systems. A
back door is an undocumented way of accessing a system that bypasses normal authenticated mechan-
isms. Unlike viruses and worms, Trojans can only spread through human interaction such as down-
loading files or opening email attachments.73 Often Trojans arrive in the form of a joke or other email.
Bots (derived from the word robot) can be used either maliciously or for good. Bots are used to
automate tasks usually undertaken by a human being. A typical use of bots is to gather information.
A malicious bot is designed to infect the host and connect back to a server, from which someone can
launch remote control attacks on their target. Bots can self-propagate like a virus or a worm. Bots have
the ability to log keystrokes, gather passwords, launch denial of service (DoS) attacks, deliver spam and
open back doors (often already opened by a virus or worm). Bots often infect networks in a way that
escapes immediate notice so the damage is done before they are detected.74

Spam
Spam is the sending of unsolicited emails or junk email. Spam is also a common technique for spreading
viruses. The content of spam is sometimes offensive to those receiving it; for example, invitations to pur-
chase drugs and links to adult-oriented sites. The content can also trick the unwary into being defrauded,

650 PART 4 Systems issues

for example, by falling for a ‘Nigerian’ scam,75 where the victim is recruited to help the fraudster claim a
(non-existent) amount from a dormant bank account in exchange for a share of the proceeds. The victim is
then lured into making a series of progressively larger payments to meet so-called upfront fees. Australia’s
national computer emergency response team (CERT) provides information for Australians and Australian
businesses on how to better protect their information technology from cyber-based threats and vulnerabil-
ities. CERT is the initial contact point for cyber-related incidents that impact on Australian networks. The
Scamwatch website alerts businesses and individuals to scams that take place over the internet.76 Many of
these originate from overseas, which means that the perpetrators are difficult to track down and prosecute.

Identity crime
In a 2014 report, Identity Crime and Misuse in Australia,77 the economic impact of identity crime was esti-
mated to be more than $1.6 billion each year. One of the biggest limitations is that identity crime is under-
reported. One of the challenges is the lack of commonly agreed terms, although there is some consensus on
some definitions. Internet scammers use various techniques to obtain personal information so that the per-
petrators are able to steal identities. Among the most common approaches to identity crime78 are as follows.
•• Phishing — the word ‘phishing’ comes from the notion that ‘internet scammers are using email lures
to “fish” for passwords and financial data from the sea of internet users’.79 Scammers trick a person
into giving out personal information such as bank account details and passwords via email, social
media, phone call, or text message. Scammers pretend to be a legitimate business and the messages
look genuine. Some forms of phishing include:
–– whaling and spear phishing, where a business is targeted in an attempt to obtain confidential
information with fraudulent intent.
–– pharming, where the scammer redirects the victim to a fake website that looks genuine by infecting
the computer with malware.80
•• Hacking — when a scammer gains access to personal information by using technology to break into
a computer, mobile device or network.81
Growth in the digital economy has provided opportunities and benefits for businesses, governments
and individuals; some of these benefits include increased efficiencies in business processes, higher quality
service delivery and the ability to work from any location. It is important that, as people engage with
the digital economy, they are able to trust the identity of the people they are dealing with, particularly
when dealing with high-value or sensitive information. A major risk is criminal misuse of an individual’s
identity, which is called identity crime. Identity fraud is one of the most prevalent criminal activities
and affects many Australians each year. This is where stolen personal information is used by criminals
to create fraudulent documents, known as identity fabrication, to commit crimes such as accessing
government benefits and services they are not entitled to, defrauding banks and other institutions, and
even human trafficking and other serious offences.82 Identity manipulation occurs when criminals
either create a fictitious identity or steal all or part of the identity of another person, either living or dead.
Identity misuse occurs when criminals obtain or use personal information without permission.83 When
a fraudster assumes someone else’s identity and opens bank accounts, applies for loans or conducts other
business, this is known as identity takeover, while identity theft is the crime of impersonating another
person by using their personal information to conduct transactions and other fraudulent activity.
A standard set of definitions has been developed by the Australian Transaction Reports and Analysis
Centre’s Proof of Identity Steering Committee for use by law enforcement throughout Australia (ACPR
2006:15).
Criminals use techniques to manipulate people into providing confidential information. The type of
information may include passwords, bank details or access to a computer to install malicious software.
This is called social engineering and relies on exploiting a person’s natural inclination to trust.84 The
weakest link in any security chain is people.
Hardware and software controls have increased in sophistication to counter attacks from phishing,
pharming and bots. However, humans are still the weakest link, both those inside the organisation and

CHAPTER 14 Ethics and cybercrime 651

those who attack from outside. Employees pose the most dangerous threats because of their intimate
knowledge of the organisation, organisational systems and customers.85
To illustrate some of the tactics used by hackers, consider this scenario. You receive an sms from your
bank asking you to log in and change your password. You use the link to go to the website, which looks
genuine. You enter your user name and password. Later you realise it is a fraudulent site. The scammers,
who may be from anywhere in the world, now have the details to log in to your account. The scammers
will attempt to access your account and take the money from your account before you realise what has
happened. This is phishing. This is a real threat for organisations. Websites are relatively easy to create
and domain names are easy to acquire. This leaves organisations vulnerable to phishing scams that
damage customer trust in the organisation and e-commerce, as well as denting the organisation’s image.
Organisations can overcome some of the risks involved through information about IT usage and policies
and ensuring that customers are aware of the policies. For example, one policy could be that the organ-
isation will never request personal details by email or will not communicate at all with users by email.
Users aware of this policy would, it is hoped, be alerted to attempts at phishing.
A CEO became a victim of social engineering when someone took advantage of the knowledge that
a member of the CEO’s family had survived cancer. The CEO had become interested in cancer support
and research. The scammer used Facebook to find out more information about the CEO’s fundraising
efforts and personal details such as his favourite restaurant. The scammer called the CEO posing as a
fundraiser. The CEO agreed for the scammer to send a .pdf document to his email address. This .pdf
document, when opened, installed a shell on his machine providing full access for the hacker. People
who should know better fall for these scammers. For example, a study by security firm Bitfinder86 found
that all it takes is a sexy woman for 75 per cent of people to give away their personal details! This tech-
nique is an example of social engineering.
Consider the well-documented News of the World hacking scandal, described in AIS Focus 14.3.

AIS FOCUS 14.3

News of the World

The News of the World newspaper had a long and proud history. It was first published in 1843 and at
one time was the biggest-selling English-language newspaper in the world. From 1984, the paper con-
centrated on celebrity and populist news, such as exposing scandals about celebrities and politicians.
During 2011, it emerged that the News Corporation-owned tabloid had, for a number of years, hacked
into the phones of high-profile celebrities and civilians, and even the Royal Family, for a story. There
were accusations that not only were journalists hacking into phones, but that the metropolitan police
and politicians had done nothing to investigate the allegations over many years. Among the allegations
were that News of the World journalists had hacked into the phones of bereaved military families,87
had hacked into emails and had engaged in other improper conduct. News of the World management
argued that they did not know this was occurring, although there was some evidence to suggest that
they may have sanctioned this behaviour.88 This subsequently led to the News of the World newspaper
being shut down, with 200 jobs lost.

14.5 Fraud, online fraud and scams

LEARNING OBJECTIVE 14.5 Evaluate the impact of fraud on organisations.
Fraud and scams refer to dishonest schemes that take advantage of unsuspecting people to gain a benefit
such as money or access to personal details.89 Online fraud includes internet banking fraud, shopping
and auction site fraud, scams, spam and identity theft.90
It is difficult to establish the exact cost to the economy of online fraud, but the worldwide financial
impact is estimated to be more than $US3.7 trillion each year.91 PwC’s 2014 Global Economic Crime

652 PART 4 Systems issues

Survey: The Australian Story92 found that the total cost of fraud is increasing: in 2014, 57 per cent of
Australian respondents reported that they had experienced economic crime, an increase of 10 per cent
from 2012. The Australian Institute of Criminology cautions that estimates are difficult to establish;
however, their research estimates that fraud cost Australia $6 billion in 2011.93 Internal fraudsters are
likely to be middle management, aged between 31 and 40 years, primarily male (however, female fraud-
sters are on the increase) and qualified graduates. External fraudsters are increasingly customers.94
There are several possible ways to act fraudulently in the world of information systems. Consider the
following:
•• the payroll manager who places a non-existent staff member on the payroll and collects his or her
salary in addition to his or her own
•• the programmer who adjusts a payroll program so that 1 cent from every pay every week goes to an
account he or she has created
•• the hacker who gains credit card numbers with the intent of using them for personal gain
•• the person who creates a website purporting to be that of a large organisation and gains private
customer details (including bank account details) through the site.
Fraud is a real problem for organisations and, as was alluded to in chapter 8 on internal controls, the
growth of e-commerce has heightened consumer and organisational awareness of the very real risk that
fraud presents.
According to auditing standard ASA 240 The Auditor’s Responsibilities Relating to Fraud in an Audit
of a Financial Report, paragraph A25, there are three risk factors known as the ‘fraud triangle’ that are
generally present when a fraud is committed. These are:
•• an incentive or pressure to commit fraud
•• a perceived opportunity to commit fraud
•• an ability to rationalise the fraudulent action.
The pressure to commit fraud can come from various sources, including the individual’s personal
life and work environment. Consider, for example, a bank teller who is experiencing pressure at home,
with mortgage payments rapidly approaching and credit cards nearing their limit. This financial pressure
may be an incentive for the teller to ‘borrow’ some of the bank’s cash to place a bet on a ‘sure thing’
at the Saturday races with the intention of returning the cash to the bank on Monday morning. Another
example could be the corporate accountant who is under pressure to achieve financial targets, so as not
to disappoint the sharemarket. Consequently, he or she creates fictitious sales to boost revenue and bol-
sters the value of inventory and assets through revaluations. These are two examples of pressures that
can lead to fraud: the first personal and the second job related.
The opportunity refers to the individual’s perceived ability to carry out the fraud and conceal the
fraudulent activity. In the bank teller case, the opportunity was available because the teller could take the
money on Friday night and return it on Monday, and no-one would be any the wiser.
The reason is the way that individuals justify their fraudulent activity. For example, the bank teller
who takes some cash home on a Friday night and bets it on a ‘sure thing’ over the weekend may justify
these activities on the basis that no-one will get hurt and, when the horse wins, the original amount of
money can be returned. In effect, the teller was only borrowing, albeit unethically.
Research studies have found that the incidence of fraud tends to be related to the ethical environment
of the organisation. This makes ethics and the promulgation of ethical values and practices vitally impor-
tant to the organisation. They can be promoted through, for example, codes of conduct and professional
registration. Codes of conduct or ethical standards provide guidelines for acceptable behaviour. For
example, ethical guidelines exist to guide auditors when making client acceptance decisions, when deter-
mining the level of non-audit service fees and on what gifts from the client can be accepted. Similarly,
both the Australian and New Zealand computer associations have a code of conduct for their members
to follow. It is important that such codes have the ability to impose significant and enforceable sanctions
against any failure to comply by members — mere voluntary membership of professional organisations
can reduce the efficacy of such codes.

CHAPTER 14 Ethics and cybercrime 653

 Membership of a profession carries benefits; for example, professions typically possess a base of
knowledge that is valued in society (as with doctors or accountants), professional authority is recog-
nised in the wider community that they serve, and a professional culture and ethical codes govern their
actions.95 Codes of ethics can be both formal and informal, and enforced by the self and by the pro-
fessional body. For example, the professional accounting bodies hold disciplinary meetings for alle-
gations of breaches of the codes of conduct. For professionals who consider themselves a part of the
professional group, such as a CA or CPA or a doctor, the prospect of being disciplined and potentially
excluded from the group and prevented from earning their livelihood is generally a strong enough means
of ensuring behaviour in accordance with the professional code of ethics.
Organisations can therefore help induce ethical behaviour by having employees who are members of
professional bodies that enforce a professional and ethical code of conduct, or by creating and enforcing
their own ethical code of conduct, to which the employee signs up when joining the organisation.

Sales fraud or e-commerce fraud

Some hypothetical examples of sales fraud or e-commerce fraud are discussed in this section. In the
exercises at the end of this chapter you have the opportunity to develop some control plans that could be
applied to reduce the risk of these occurring.
Example 1: Paying non-existent suppliers or false invoices
John MacIntosh, a payment clerk for Deep Water, creates a company called ABC Enterprises. ABC
Enterprises then proceeds to issue invoices to Deep Water, where John is responsible for approving and
paying them. Several invoices, valued at several thousand dollars, are processed and paid by Deep Water,
with the money going to MacIntosh.
Example 2: Credit fraud
Susan Falmer purchases items online using credit card numbers that she has obtained illegally through a
phishing scheme she established a few years ago. She purchases the items on credit and then sells them
to customers over the internet at prices much less than retail. Because the credit card details were stolen,
Susan never incurs any of the debts. The company selling the goods to Susan never incurs any debt
because credit transactions are guaranteed by credit card companies. Of course, in the long run all credit
card users bear the cost of Susan’s fraud because card companies factor fraud losses into their charges.
Example 3: Non-existent sales
The end of the financial year is fast approaching and GHI Ltd is slightly below its budgeted fore-
cast sales, which were released to the stockmarket with mid-year earnings figures. Recognising that
lower-than-expected earnings would send a poor signal to the market, the chief financial officer of GHI
Ltd instructs the financial accountant to push forward some sales, recognising them in the current period,
even though the inventory is yet to be shipped. For GHI this has several benefits: it increases its sales
figures, and its asset base also increases through the higher accounts receivable. The accountant responds
by calling up some pending sales orders on the system and altering their status, thus recognising them
as sales. The following year, however, will show reduced sales as a result, and the chief financial officer
may be under more pressure to anticipate even more sales transactions.
Example 4: Nonexistent customers
Brad is the accounts receivable manager at Tee Up Ltd, a seller of golfing accessories. A keen golfer
himself, Brad would like to use the products of Tee Up but is unable to afford them. To overcome this
difficulty Brad creates fictitious customers on the accounts receivable master list, with addresses that
correspond to those of his close friends. As Brad orders goods through these customers, the goods are
shipped to the addresses, where Brad collects the goods. Payment is never received from Brad for the
goods. Instead he records the goods returned by the customer due to damage (damaged returns do not go
to inventory but are written off as an expense), writes the account off as a bad debt or clears the accounts
receivable amount owing through non-cash entries such as allowances and returns.

654 PART 4 Systems issues

Example 5: Inventory theft
Jenny is a disaffected ex-employee of Magna Corp, a supplier of high-quality, expensive audio com-
ponents. Masquerading as a buyer for The Sound Shop, a large retail chain and Magna customer, Jenny
phones an order worth several hundreds of thousands of dollars to Magna and arranges for the order to
be delivered the following morning. The Magna driver arrives at The Sound Shop inward goods dock as
arranged and thrusts a delivery receipt in front of Gary, the receiving storeman, collects Gary’s signature
and unloads the shipment. Gary then hunts through his computer system and, not surprisingly, can find
no trace of this order. When the Magna truck delivered the order, Jenny’s boyfriend Tim was waiting
in a van parked outside The Sound Shop’s gate, wearing a Magna logo shirt. Tim drives up with a very
plausible story: ‘Terribly sorry, our driver delivered an order to you in error, it was meant for another
customer’. A relieved Gary loads the shipment into Tim’s van. Tim and Jenny subsequently sell the items
for cash from a shop that they rented for a week for that purpose and vanish without trace. Magna duly
invoices The Sound Shop, who repudiate the invoice. After both companies have spent several months
investigating the issue, Gary remembers a young man in a van picking up the goods. However, this
remains undocumented and Magna deny all knowledge. Ultimately Magna insist, ‘You received it, your
employee Gary signed for it, you must pay for it’.

14.6 Reducing the risk of cybercrime

LEARNING OBJECTIVE 14.6 Describe and evaluate controls that reduce the risk of crimes facilitated by
technology.
In chapters 8 and 13, we discussed the importance of good corporate governance and good IT governance.
Internal control and risk management are important components of good corporate and IT governance.
In the US, insiders — including current and former employees, service providers and contractors —
were responsible for 28 per cent of cybercrime events.96 It is important to note that small businesses are
particularly vulnerable because they are unlikely to have the same fraud prevention and detection con-
trols as larger organisations.97
The presence of anti-fraud controls is associated with reduced fraud and shorter fraud duration. Col-
lusion helps insiders to evade independent checks and other anti-fraud checks. Collusion is where two
or more people (e.g. two or more employees, a supplier and an employee, a customer and an employee)
secretly agree to defraud or deprive others of their property. Fraud detection controls include external
audit, employee code of conduct, internal audit department, rewards for whistleblowers, job rotation/
mandatory vacation, surprise audits, formal fraud risk assessments, proactive data monitoring/analysis,
dedicated fraud department, function or team anti-fraud policy, fraud training for employees, fraud
training for managers/executives, employee support programs, hotline, independent audit committee,
management review. Interestingly, external audit is one of the least effective controls for detecting
insider fraud. Anti-fraud controls that have been found to be effective include proactive data monitoring,
surprise audits, a dedicated fraud department or team and formal fraud risk assessments.98
Management need to consider the most appropriate anti-fraud controls according to the potential risks
for their specific business. The COSO and COBIT frameworks discussed in chapters 8 and 9 are impor-
tant frameworks that can be utilised to reduce the risk of fraud and online fraud.
Scams to fraudulently obtain money or information are common. It is important that managers and
employees are kept informed of the latest scams; for example, by keeping up to date with Scamwatch.99
There is also a mechanism for reporting scams.100
Understanding how users behave and how they react in particular situations is important so that the
human and technology aspects of security are integrated. Stajano and Wilson101 distilled seven recurring
behavioural patterns and related principles that provide some insight into human behaviour.
1. Distraction principle. This is where the scammer distracts the potential victim away from the
scam to something they desire. This is used in many scams. One example is the Nigerian scam,
where the hustler poses as a Nigerian government official with access to tens of millions of dollars

CHAPTER 14 Ethics and cybercrime 655

 and needs you to move it out of the country. If you accept the deal, you are then asked to pay for
expenses. Unexpected expenses then keep coming up while waiting for the huge sum to arrive in
your account.
2. Social compliance principle. People do not generally question authority. Social compliance is the
foundation for phishing and social engineering. For example, you are more likely to provide per-
sonal information to someone on the phone who purports to be a police officer or other authority
figure.
3. Herd principle. This is where something is made to look legitimate because everyone else is doing it.
In online auctions, for example, frauds are possible if bidders are in partnership with the auctioneer.
In social networking, multiple aliases can be created to give the impression that many people share
the same idea or have the same opinion.
4. Dishonesty principle. Once a person realises that they have been involved in a scam — if it relates to
something illegal like money laundering (as in the Nigerian example above) or to pornography — the
victim may be reluctant to tell the authorities.
5. Kindness principle. People are nice and want to help. Scammers often take advantage of this through
social networking sites or email, presenting a sad story or a natural disaster where people are happy
to contribute their money. Social engineering also relies on the kindness of people.
6. Need and greed principle. Once people know our needs and wants, they can manipulate us. For
example, if someone is just about to lose their house because they lost their job, the promise of a lot
of money is very tempting.
7. Time principle. When under time pressure, we make decisions using less reasoning. You are made an
offer you cannot refuse or that asks you to do something quickly. For example, in a phishing situ-
ation, you may receive an email that tells you that, if you do not log in with your details, you will lose
access to your account.

14.7 Future trends and issues with new

technologies
LEARNING OBJECTIVE 14.7 Appraise new trends and issues associated with new technologies.
Technology is developing quickly and it is difficult to predict what the future may hold. New issues will
always emerge. Pimple (2011)102 outlined a chilling future where people are always being watched, there
is no privacy and every decision is controlled by some unknown force. Maybe this is already happening!
The Internet of Things (IoT) is a term used to explain the connectivity of devices. Embedded sensors,
processors, software, and connectivity in all types of products which, along with cloud computing, have
the potential to change the way we live, work and play. Porter and Heppelmann (2014) argue that IoT
has the potential to drive productivity increases and economic growth.103 Pervasive computing, ubiqui-
tous computing and ambient intelligence are all terms used for technologies that are integrated into our
everyday lives. Many of these technologies are already invisible and taken for granted. For example, a
smartphone’s map function is very useful, but to use it GPS must be turned on, which tracks the phone’s
(and therefore the user’s) location. Although there are many benefits of these technologies, to be useful
the applications need to be personalised. Personalisation is only effective if you provide enough per-
sonal information to receive the service you need. The issues raised relate to coercion, surveillance and
control.
Some predictions about technology for the near future are outlined in a World Economic Forum
blog.104
1. The ‘humanised’ internet where personalisation is taken to another level where devices will ascertain
patterns and needs.
2. The Internet of Things will no longer be about things. Every business will become an IoT which will
transform businesses from product-centric to service-centric business models.

656 PART 4 Systems issues

3. 3D printing of organs will transform medicine.
4. The internet of everywhere so that the digital divide is eradicated and everyone will have access to
the internet wherever they are and whatever their income levels.
5. Learning on the job will never stop because new technologies will require different skills. Technology
is already disrupting existing jobs and creating new jobs that never existed before.
What do you think of these trends? Are they exciting and challenging? What ethical issues do they
raise? How can individuals, organisations and society deal with these trends?

SUMMARY
14.1 Discuss the way ethical theories provide a basis for decision making in organisations.
All types of business (including not-for-profit) and government entities need to consider the ethical
implications of their actions. Businesses and governments have control of the world’s resources, and
managers make decisions every day that affect those resources and the lives of millions of people. It is
important that those who operate within the business world have an understanding of ethical theories and
philosophies to help guide their decision making.

14.2 Solve an ethical dilemma by applying an ethical decision-making model.

The ethical decision-making model represents a way of working through ethical dilemmas. There
are seven stages in the model: (1) identify the facts, (2) define the issues, (3) identify the principles,
(4) identify possible actions and those affected, (5) compare steps 3 and 4, (6) select an action or out-
come, and (7) implement the action chosen in step 6.

14.3 Explain and give examples of ethical issues relating to accounting information systems.
The ethical problems related to accounting information systems vary, depending on the perspective
from which they are viewed. These include issues from the customer’s perspective, which can be the
right to privacy, the accuracy of information being gathered and the use of information that is gathered
about customers. From an organisation’s perspective, ethical issues include how the resources of the
accounting information system are used within the organisation and ensuring that usage matches the pur-
pose for which the information was originally gathered. Employees’ use of the accounting information
system and the broader set of IT resources is another issue for organisations. This can include the use
of email and the internet. A social issue that is emerging as e-commerce becomes increasingly prevalent
is that of access to the technology required to support e-commerce and the potential discrimination and
alienation that can emerge.

14.4 Discuss and provide examples of cybercrime.

Computer crime can be broadly defined, potentially including crimes committed through the use of a
computer and crimes where computers are the object of the crime. This creates a range of potential
actions that could fall within the scope of computer crime.
Spam, phishing, identity crime and hacking are threats in the increasingly popular world of
e-commerce. Spam is the sending of unsolicited emails and exposes the organisation to excessive email
traffic and potential viruses and computer attacks. Phishing and identity fraud affect the validity of trans-
actions that individuals and organisations engage in, as individuals pretend to be others through the
fraudulent use of websites (phishing) or personal details such as credit card numbers and other identi-
fying traits (identity theft). Hacking is someone gaining unauthorised access to a system. These areas all
represent threats to the effective running of an accounting information system within the organisation.
14.5 Evaluate the impact of fraud on organisations.
The impact of fraud is significant, not just from a cost perspective but also from the perspective of an
organisation’s reputation. The cost of fraud worldwide is increasing and the financial impact is estimated

CHAPTER 14 Ethics and cybercrime 657

to be in the trillions. The profile of internal fraudsters is of employees in middle management pos-
itions, aged between 31 and 40 years and primarily male (although the number of female fraudsters is
increasing). External fraud is often committed by customers.
The three risk factors (the fraud triangle) are the incentive or pressure to commit fraud, a perceived
opportunity to commit fraud and the ability to rationalise fraudulent action. The incidence of fraud tends
to be related to the ethical environment of the organisation.

14.6 Describe and evaluate controls that reduce the risk of crimes facilitated by technology.
There are various ways to reduce the risk of computer crime. The establishment of a sound internal
control policy can be a good start. Other strategies include codes of conduct and registration with pro-
fessional bodies, as these can be ways of encouraging ethical behaviour and a shared set of attitudes and
beliefs throughout the organisation.

14.7 Appraise new trends and issues associated with new technologies.
Technology is developing quickly and it is difficult to predict what the future may hold. New issues
will always emerge. Predictions about the benefits of technology are exciting, but also raise some very
important ethical concerns that may involve issues that have not even been thought of yet.

KEY TERMS
Bot Short for ‘robot’, an automated process that interacts with other networks.105
Consequentialist theories Theories that argue that the consequences of one’s actions should be the
basis for making an ethical decision.
Cookies Small files stored on a computer’s hard drive that keep a record of websites viewed, viewing
preferences and user profiles.
Customer profiling A process where data on a customer’s website viewing habits are used to build a
profile of their interests, needs and preferences, which can then be used for targeted advertising.
Cybercrime A crime committed using a computer and/or the internet.
Data mining A data analysis technique where large amounts of data are taken and analysed for
potential patterns and relationships that may exist.
Ethics The term given to the implicit rules that guide us in our everyday behaviour, thoughts and
actions.
Fraud An act on behalf of a person that is deceptive or deceitful in some way in that it causes them to
receive a benefit that they are not entitled to.106
Hacking Gaining unauthorised access to a system.
Identity crime A generic term that describes a range of activities/offences where a perpetrator uses
an identity (some combination of personal information) that is fabricated, manipulated, stolen or
assumed from another person in order to facilitate the commission of a crime(s).107
Identity fabrication The creation of a fictitious identity.108
Identity fraud Gaining money, goods, services or other benefits, or avoiding obligations by using a
fabricated, manipulated or stolen/assumed identity.109
Identity manipulation Altering one or more elements of an identity (e.g. name, date of birth,
address etc.).110
Identity misuse Using personal information for purposes extraneous to the original transaction —
such as renting it to a vendor of related products, or mining it to create a consumer profile or direct
marketing list.111
Identity takeover Assuming parts or all of the identity of another person without their consent.112
Identity theft Stealing or assuming a pre-existing identity (or significant part thereof) without consent
and, in the case of an individual, whether the person is living or deceased.113

658 PART 4 Systems issues

Kantianism A theory proposed by Kant that an action is morally right if it is motivated by a good will
that stems from a sense of duty.
Malware Malicious code that is designed to damage, disrupt or steal data or disrupt computer systems
and networks.
Maxim A rule or principle on which one acts.
Non-consequentialist theory The theory that a decision or action should be based on duties and rights
(or obligations).
Online fraud Any type of fraud scheme that uses email, websites, chat rooms or message
boards to present fraudulent solicitations to prospective victims, to conduct fraudulent
transactions, or to transmit the proceeds of fraud to financial institutions or to others connected
with the scheme.114
Personal information Information or an opinion about an identified individual, or an individual who
is reasonably identifiable.
Phishing Using email to seek passwords and financial data from internet users.
Privacy The claim of individuals, groups, or institutions to determine for themselves when, how, and
to what extent information about them is communicated to others.
Radio frequency identification (RFID) A system that transmits the identity (in the form of a unique
serial number) of an object or person wirelessly, using radio waves. It is grouped under the broad
category of automatic identification technologies.
Spam The sending of unsolicited emails or junk email.
Trojan Named after the mythical wooden horse used to gain access to Troy. It is a harmful piece of
software that looks legitimate.115
Utilitarianism The theory that the decision or action is right if it creates happiness for the greatest
number of people.
Virus A program or code that replicates; that is, infects another program, boot sector, partition sector,
or document that supports macros, by inserting itself or attaching itself to that medium.116
Whistleblower A person who informs on a person or organisation engaging in an unlawful or immoral
activity.
Worm A type of malware that is similar to a virus and causes the same type of damage, but does not
require a host program.117

DISCUSSION QUESTIONS
14.1 Why should we be concerned about ethics?(LO1)
14.2 Explain the importance of ethics in business.(LO1)
14.3 Describe the ethical decision-making model. Why is it useful to use when faced
with an ethical dilemma?(LO2)
14.4 Discuss some of the ways in which a person’s privacy may be threatened through
technology.(LO3)
14.5 Explain the key types of computer crime. (LO3, LO4)
14.6 Give examples of the types of fraud that can be perpetrated using technology.(LO5)
14.7 What are the implications of cybercrime for business?(LO4)
14.8 What are the two areas that organisations need to focus on to ensure good security?(LO6)
14.9 What are the seven principles that Stajano and Wilson believe organisations should
be aware of when designing security systems?(LO6)
14.10 What are the key areas futurists believe will be the future for technology? Do you agree or
disagree with these predictions? What are your predictions for the next decade?(LO7)

CHAPTER 14 Ethics and cybercrime 659

SELF-TEST ACTIVITIES
14.1 Ethical theories are important for managers to understand because:(LO1)
(a) their decisions should include a framework to make good decisions.
(b) they are not able to make decisions without considering the ethical issues.
(c) they have to make decisions based on the best financial outcome for the
organisation.
(d) ethics is a legal requirement .
14.2 Which of the following is not an example of online fraud?(LO5)
(a) Paying non-existent suppliers with false invoices.
(b) Credit card fraud.
(c) Non-existent customers.
(d) Phishing.
14.3 Which of the factors below were not mentioned by Stajano and Wilson as having
an influence on human behaviour?(LO6)
(a) Distraction principle.
(b) Herd principle.
(c) Technology principle.
(d) Need and greed principle.
14.4 Which of the following is not an example of malicious code (malware)?(LO4)
(a) Trojan.
(b) Virus.
(c) Bots.
(d) Social engineering.
14.5 Spam is:(LO4)
(a) Sending unsolicited emails.
(b) Acquiring personal details by means of deception.
(c) Gaining unauthorised access to a system.
(d) Pretending to be someone else in an online transaction.
14.6 Which of the following according to futurists is unlikely to be a technology
trend?(LO7)
(a) Internet of everywhere.
(b) Increased security and privacy.
(c) Jobs changing and evolving as technology disrupts more
industries.
(d) Big data.
14.7 A company discovers that an employee has created a fictitious vendor on the vendor
master file and the company has paid a total of $250  000 to this vendor through fake
invoices. This is an example of fraud in the:(LO5)
(a) revenue cycle.
(b) inventory management cycle.
(c) expenditure cycle.
(d) cash receipts cycle.
14.8 Which of the following is not needed for a fraudulent act?(LO5)
(a) A reason.
(b) Pressure.
(c) A system with weak internal controls.
(d) An opportunity.

660 PART 4 Systems issues

PROBLEMS
14.1 Review the most recent ASIC annual report available at: http://asic.gov.au/about-asic/corporate-
publications/asic-annual-reports/. Summarise the enforcement cases. Explain the implications
to the individuals, organisations and society (community) for each case.(LO1)
14.2 Review the CDPP (Australia’s Federal Prosecution Service) website. Select the ‘Fraud’
category and a specific case. Research the case. Write a short report explaining the facts, the
implications for the individual, the implications for the organisation and if there were any
lessons learned (e.g. new legislation).(LO1)
14.3 Read the article: Sawyer, Kim R 2015, ‘The invisible hand: when the firm becomes the
bully’, available through Google Scholar at SSRN 2607744. Summarise the proposed
whistleblowing model in the paper.(LO1)
14.4 Investigate the current status of the introduction of mandatory data breach laws in Australia.
Write a report on the implications of these laws for individuals, organisations and society.(LO2)
14.5 Read the following article from The Conversation by Benjamin Dean: ‘Why companies
have little incentive to invest in cybersecurity’, 5 March 2015, https://theconversation.com/
why-companies-have-little-incentive-to-invest-in-cybersecurity-37570. Formulate arguments
for and against investing in better IT security for protecting an organisation’s data.(LO3)
14.6 Summarise the differences between the Australian Information Privacy Principles (IPPs)
and the National Privacy Principles (NPPs) (prior to 12 March 2014) and the current
Australian Privacy Principles (APPs). Do the APPs provide more protection for individual’s
personal information?(LO3)
14.7 Research and write a report on the ‘right to be forgotten’ and privacy law.(LO3)
14.8 Research a case study on the Doubleclick website: www.doubleclickbygoogle.com/.
Write a report summarising the process used by Doubleclick and specific ethical and
privacy issues that arise from the process.(LO3)
14.9 Research the latest statistics on cybercrime in Australia and around the world. Explain the
most important initiatives that can be taken by governments, organisations and individuals
to reduce cybercrime. In your answer compare and contrast cybercrime statistics between
Australia and other countries.(LO4)
14.10 Review the Scamwatch website: www.scamwatch.gov.au/. Select a scam under ‘Types of
Scams’. Explain how the scam works, how you can protect yourself from this scam and the
implications of the scam for individuals, organisations and society.(LO4)
14.11 Read the article, ‘What damage does social engineering really cause anyway?’, at
www.social-engineer.org/general-blog/what-damage-does-social-engineering-really-cause-
anyway/#sthash.GMTAq28B.dpuf. Summarise the way social engineering was used in the
hacks discussed in the article.(LO4)
14.12 Go to the Think Jessica website: www.thinkjessica.com. Read Jessica’s story. Explain
the implications of fraudulent mail and emails.(LO5)
14.13 Investigate a recent data breach. What was the cause? What were the implications? (LO5)
14.14 Review the privacy statements on the following websites: Westpac, Qantas, Air
New Zealand, Woolworths and the Australian Taxation Office. Compare each with the
Australian Privacy Principles discussed in the chapter. Do the privacy statements comply? (LO6)
14.15 In teams of six, investigate the National Broadband Network (NBN) in Australia or the
Ultra-fast Broadband Initiative in New Zealand. Three team members research the pros of
the project and three team members research the cons of the project. Organise the
outcomes as a debate as to the pros and cons of the NBN or the Ultra-fast rollout.(LO3)
14.16 Review the Australian government Scamwatch website: www.scamwatch.gov.au. In teams
of three, identify one of the latest scams. Outline the scam and provide a recommendation
for the steps that could be taken to ensure this scam is unsuccessful.(LO4)

CHAPTER 14 Ethics and cybercrime 661

14.17 SellItNow is an online company that sells hardware products for new houses to both industrial
clients and individual consumers. As a result of its very competitive price schemes, SellItNow
has developed an extensive customer base, which is reflected in its burgeoning database of
customer details, purchasing history and internet usage data. Recognising that these data are
potentially valuable to third parties, SellItNow’s directors discuss the prospect of selling its
customer database to a large insurance company, thus allowing the insurance company to target
advertising and mailouts about home and contents insurance packages to new home buyers.
The directors are split on the issue — some view this as an exciting way to add value to their
customers through complementary product offerings, while others see it as a gross misuse of
information that is not in keeping with the original purpose for which the data were gathered.
You have been engaged by SellItNow as an ethics consultant and have been requested to
advise it on the possibilities that exist to resolve the boardroom debate. (LO2)
Required
Work through the steps of the ethical decision-making model and evaluate what SellItNow
should decide and what it should do.
14.18 Watch the video, ‘A futuristic short film HD’ by Sight Systems at www.youtube.com/
watch?v=lK_cdkpazjI. Summarise the legal and ethical issues raised in the video.(LO7)
14.19 Read the article, Porter, M & Heppelmann, J 2014, ‘How smart, connected products are
transforming competition’, Harvard Business Review, vol. 92, no. 11, pp. 64–88. Explain
how the five forces may potentially change the competitive landscape and the structure of
industries.(LO7)

FURTHER READING
ASIC 2013–2014 Annual Report, http://asic.gov.au/about-asic/corporate-publications/
asic-annual-reports/.
Association of Certified Fraud Examiners 2014, Report to the nations on occupational fraud and
abuse: 2014 global fraud study, www.acfe.com/rttn/docs/2014-report-to-nations.pdf.
Baker, M 2015, ‘The cost of cybercrime to Australian businesses’, blog, 1 July, www.empowerit.com
.au/blog/security/the-cost-of-cybercrime-to-australian-businesses/.
Chryssides, GD & Kaler, JH 1995, An introduction to business ethics, Chapman & Hall, London,
pp. 80–107.
Clark, N 2010, ‘Rogue trader at Société Générale gets 3 years’, New York Times, www.nytimes.com.
Dellaportas, S, Gibson, K, Alagiah, R, Hutchinson, M, Leung, P & Van Homrigh, D 2005, Ethics,
governance and accountability, John Wiley & Sons Australia, Brisbane.
Fullerton, T 2011, ‘A rogue trader, a Swiss bank and another financial scandal’, ABC.net.au.
Hartman, LP 2005, Perspectives in business ethics, 3rd edn, McGraw-Hill, New York.
Kant, I 1964, Groundwork of the metaphysic of morals, trans. HJ Paton, Harper and Row, London, as
cited in Chryssides, GD & Kaler, JH, op. cit.
Law, S 2007, The great philosophers: the lives and ideas of history’s greatest thinkers, Querus
Publishing Plc, London.
Liebowitz, M 2011, ‘Sexy women coax passwords out of hackers’, MSNBC, www.msnbc.com.
Pimple, KD 2011, ‘Computing ethics surrounded by machines’, Communications of the ACM, vol. 54,
no. 3, March 2011.
Porter, M & Heppelmann, J 2014, ‘How smart, connected products are transforming competition’,
Harvard Business Review, vol. 92, no. 11, pp. 64–88.
Prenzler, T 2012, ‘Responding to welfare fraud: the Australian experience’, Research in Public
Policy Series no. 119, Australian Institute of Criminology, Canberra, www.aic.gov.au/publications/
current%20series/rpp/100-120/rpp119.html.

662 PART 4 Systems issues

PwC 2014, Global economic crime survey 2014, www.pwc.com/gx/en/economic-crime-survey/.
Qing, H, Zhengchuan, X, Tamara, D, Hong, L 2011, ‘Does deterrence work in reducing information
security policy abuse by employees?’, Communications of the ACM, vol. 54, no. 8, June.
Stajano, F & Wilson, P 2011, ‘Understanding scam victims: seven principles for system security’,
Communications of the ACM, vol. 54, no. 3.
St James Ethics Centre, ‘What is ethics? Ethical decision making’, www.ethics.org.au.
Vasalou, A, Joinson, A & Houghton, D 2015, ‘Privacy as a fuzzy concept: a new conceptualization of
privacy for practitioners’, Journal of the Association for Information Science and Technology,
vol. 66, iss. 5, pp. 918–29, doi: 10.1002/asi.23220.

SELF-TEST ANSWERS
14.1 a, 14.2 a, 14.3 d, 14.4 d, 14.5 a, 14.6 d, 14.7 d, 14.8 c

ENDNOTES
1. Philosophy at Lander, http://philosophy.lander.edu/ethics/epicurus.html.
2. Stanford Encyclopedia of Philosophy, http://plato.stanford.edu/entries/socrates/.
3. Law, S 2007, The great philosophers: the lives and ideas of history’s greatest thinkers, Querus Publishing Plc, London.
4. Adapted from Dellaportas, S, Gibson, K, Alagiah, R, Hutchinson, M, Leung, P & Van Homrigh, D 2005, Ethics, governance
and accountability, John Wiley & Sons Australia, Ltd, Brisbane.
5. Chryssides, GD & Kaler, JH 1995, An introduction to business ethics, Chapman & Hall, London, pp. 80–107.
6. Hartman, LP 2005, Perspectives in business ethics, 3rd edn, McGraw-Hill, New York.
7. ibid.
8. Kant, I 1964, Groundwork of the metaphysic of morals, trans. Paton, HJ, Harper and Row, London, as cited in Chryssides,
GD & Kaler 1995.
9. ‘Corporate fraud on the rise post-GFC’, Risk Management, www.riskmagazine.com.au; Dellaportas, S, Gibson, K, Alagiah, R,
Hutchinson, M, Leung, P & Van Homrigh, D 2005, Ethics, governance and accountability, John Wiley & Sons Australia, Ltd, Brisbane.
10. PwC 2014, ‘Global economic crime survey 2014’, www.pwc.com/gx/en/economic-crime-survey/.
11. ASIC, Annual Report 2013–2014, http://asic.gov.au/about-asic/corporate-publications/asic-annual-reports/, p. 5.
12. ibid., pp. 45–46.
13. Sawyer, KR 2015, ‘The invisible hand: when the firm becomes the bully’, http://papers.ssrn.com/sol3/papers
.cfm?abstract_id=2607744.
14. Based on an idea from Santa Clara University Markkula Center for Applied Ethics.
15. ‘Kennedys Lawyers Australia plans mandatory data breach notification laws — will this speed take up of cyberliability
policies?’ 30 July 2015, www.kennedyslaw.com/article/AUdatabreach/.
16 PwC 2015, ‘The global state of information security survey 2015’, www.pwc.com/gx/en/consulting-services/information-
security-survey/key-findings.jhtml.
17. KrebsOnSecurity 2015, ‘Online cheating site AshleyMadison hacked’, 15 July, http://krebsonsecurity.com/2015/07/
online-cheating-site-ashleymadison-hacked/#more-31650.
18. Buchanan, B 2015, ‘Ashley Madison breach reveals the rise of the moralist hacker’, The Conversation, 22 July,
https://theconversation.com/ashley-madison-breach-reveals-the-rise-of-the-moralist-hacker-44996.
19. Fleisher, L, ‘“Adult” dating site hacked, personal details leaked, WSJ.D, blog, 22 May, http://blogs.wsj.com/digits/2015/05/22/
adult-dating-site-hacked-personal-details-leaked/ 22 May 2015.
20. Baker, LB & Finkle, J 2011, ‘Sony PlayStation suffers massive data breach’, www.reuters.com, 26 April.
21. Acohido, B 2011, ‘Sony PlayStation Network data breach timeline’, The Last Watchdog on Internet Security, 26 May,
http://lastwatchdog.com.
22. Konstantas, J 2011, ‘What does the Sony PlayStation Network breach teach us about cloud security?’, Security Week, 30 June,
www.securityweek.com.
23. Vasalou, A, Joinson, A & Houghton, D 2014, ‘Privacy as a fuzzy concept: a new conceptualization of privacy for
practitioners’, Journal of the Association for Information Science and Technology, vol. 66, pp. 918–29, doi: 10.1002/asi.23220.
24. Westin, AF 1967, Privacy and freedom, Atheneum, New York, p. 25.
25. Privacy Amendment (Enhancing Privacy Protection) Act 2012 (Cth) (Amending Act), 36 Subsection 6(1) (definition
of personal information), www.comlaw.gov.au/Details/C2012A00197.
26. Bunn, A 2015, ‘The curious case of the right to be forgotten’, Computer Law & Security Review, vol. 31, iss. 3, June,
pp. 336–350.

CHAPTER 14 Ethics and cybercrime 663

27. Privacy Amendment (Enhancing Privacy Protection) Bill 2012, www.comlaw.gov.au/Details/C2012B00077/Explanatory%20
Memorandum/Text.
28. See www.privacy.org.nz/the-privacy-act-and-codes/privacy-act-and-codes-introduction/.
29. See www.oaic.gov.au/privacy/privacy-act/the-privacy-act.
30. Lee, D 2014, ‘What is the “right to be forgotten”?, BBC News, 13 May, www.bbc.com/news/technology-27394751.
31. See http://ec.europa.eu/justice/data-protection/index_en.htm for the latest updates.
32. O’Keefe, C 2015, ‘Big data is useful, but we need to protect your privacy too’, The Conversation, 8 May,
https://theconversation.com/big-data-is-useful-but-we-need-to-protect-your-privacy-too-40971.
33. See www.zdnet.com/article/big-data-ethics-is-a-board-level-issue/.
34. See www.google.com/doubleclick/.
35. See www.google.com/doubleclick/publishers/mobile.html.
36. Rodger, W 2000, ‘DoubleClick privacy dust-up may draw regulators’ eye’, USA Today, 2 February, p. 03.D.
37. Smiley, S 2015, ‘5 examples of RFID asset tracking’, RFIDinsider, blog, 4 March, http://blog.atlasrfidstore.com/
rfid-asset-tracking-examples.
38. See Swedberg, C, n.d., ‘Baker Police Dept. finds solid evidence of RFID’s effectiveness’, RFID Journal, www.rfidjournal.com/
articles/view?12551/2.
39. Smiley 2015, op. cit.
40. Roberti, M 2015 ‘RFID is not just for big companies’, RFID Journal, 20 July, www.rfidjournal.com/articles/view?13294.
41. Smiley 2015, op. cit.
42. Swedberg, C 2015, ‘Italian schools automate lunch payments, orders’, RFID Journal, 10 July, www.rfidjournal.com/articles/
view?13257/.
43. Kravets, D 2013, ‘Student suspended for refusing to wear RFID chip returns to school, Wired, 22 August,
www.wired.com/2013/08/student-rfid-chip-flap/.
44. See ‘Texas Bill to ban active RFID in schools’, 17 March 2015, http://rfidinschools.com/.
45. Swedberg, C 2011, ‘SmartRoom brings information to patients, caregivers’, RFID Journal, 20 September,
www.rfidjournal.com/articles/view?8786.
46. Payne, S 2015, ‘Stockholm: members of Epicenter workspace are using microchip
implants to open doors’, International Business Times, 31 January, www.ibtimes.co.uk/
stockholm-office-workers-epicenter-implanted-microchips-pay-their-lunch-1486045.
47. See www.comlaw.gov.au/Details/C2015C00279.
48. See www.oaic.gov.au/privacy/privacy-act/australian-privacy-principles#_ftn1.
49. See www.comlaw.gov.au/Details/C2015C00279/Html/Text#_Toc422917669 Schedule 1.
50. See www.privacy.org.nz/the-privacy-act-and-codes/privacy-principles/.
51. Privacy Act 1988, s. 6C.
52. Swedberg, C 2011, ‘SmartRoom brings information to patients, caregivers’, RFID Journal, 20 September,
www.rfidjournal.com/articles/view?8786.
53. See www.oaic.gov.au/privacy/privacy-resources/privacy-guides/guide-to-developing-an-app-privacy-policy.
54. See www.woolworthslimited.com.au/page/Privacy_Policy/ for full privacy statement.
55. Visentin, L 2015, ‘Woolworths leaks $1 million of gift cards in massive data breach debacle’, The Sydney Morning Herald,
31 May, www.smh.com.au/digital-life/consumer-security/woolworths-leaks-1-million-of-gift-cards-in-massive-data-breach-
debacle-20150530-ghd8wl.html#ixzz3hik9uw7i.
56. See www.oaic.gov.au/news-and-events/statements/privacy-statements/woolworths-data-breach/
woolworths-data-breach-finalisation-of-enquiries.
57. Progressive Enterprises Limited, www.progressive.co.nz/contact-us/legal.
58. www.countdown.co.nz/onecard-terms-and-conditions.
59. See www.commsalliance.com.au/Activities/ispi.
60. See www.commsalliance.com.au/home.
61. Dutta, S, Geiger, T & Lanvin, B 2015, The global information technology report 2015: ICTs for inclusive growth, World
Economic Forum, Geneva, www3.weforum.org/docs/wef_global_it_report_2015.pdf.
62. ITU, ‘Statistics confirm ICT revolution of the past 15 years’, www.itu.int/net/pressoffice/press_releases/2015/17.aspx#
.Vb71l_mqqko.
63. See most recent statistics at: www.internetworldstats.com/stats.htm.
64. National Broadband Network, ‘What is the NBN?’, www.nbnco.com.au/about-the-nbn.html.
65. See Ministry of Business, Innovation & Employment 2015, ‘New Zealand’s internet upgrade’, www.med.govt.nz/
sectors-industries/technology-communication/fast-broadband.
66. See www.acorn.gov.au/what-is-cybercrime/.
67. See ACORN, ‘Learn about cybercrime’, www.acorn.gov.au/what-is-cybercrime/.
68. Australian Crime Commission 2015, Organised crime in Australia in 2015, https://crimecommission.gov.au/sites/default/files/
FINAL-ACC-OCA2015-180515.pdf..
69. Baker, M 2015, ‘The cost of cybercrime to Australian businesses’, blog, 1 July, www.empowerit.com.au/blog/security/
the-cost-of-cybercrime-to-australian-businesses/.

664 PART 4 Systems issues

 70. See www8.hp.com/au/en/software-solutions/ponemon-cyber-security-report/.
71. Baker 2015, op. cit.
72. CISCO, ‘What is the difference: viruses, worms, trojans, and bots?’, www.cisco.com/web/about/security/intelligence/
virus-worm-diffs.html .
73. ibid.
74. ibid.
75. See full explanation of the scam at: www.scamwatch.gov.au/types-of-scams/unexpected-money/nigerian-scams.
76. See www.scamwatch.gov.au/.
77. Australian Government 2014, Identity crime and misuse in Australia: key findings from the National Identity Crime
and Misuse Measurement Framework Pilot, www.ag.gov.au/RightsAndProtections/IdentitySecurity/Documents/
IdentityCrimeAndMisuseInAustralia.pdf.
78. See www.scamwatch.gov.au/types-of-scams/attempts-to-gain-your-personal-information/hacking.
79. APWG, ‘Origins of the word “phishing”’, www.antiphishing.org.
80. See www.scamwatch.gov.au/types-of-scams/attempts-to-gain-your-personal-information/phishing for a full explanation.
81. See www.scamwatch.gov.au/types-of-scams/attempts-to-gain-your-personal-information/hacking.
82. Australian Government 2014, op. cit.
83. ibid.
84. See www.webroot.com/au/en/home/resources/tips/online-shopping-banking/secure-what-is-social-engineering.
85. Qing, H, Zhengchuan, X, Tamara, D & Hong, L 2011, ‘Does deterrence work in reducing information security policy abuse
by employees?’, Communications of the ACM, vol. 54, no. 8, June 2011.
86. Liebowitz, M 2011, ‘Sexy women coax passwords out of hackers’, MSNBC, www, msnbc.com.
87. Daily Mail 2011, ‘News of the World shuts after key clients pull their adverts’, Mail Online, www.dailymail.co.uk.
88. The Telegraph 2011, ‘Phone hacking — timeline of a scandal’, www.telegraph.co.uk.
89. ACORN, ‘Online scams or fraud’, www.acorn.gov.au/what-is-cybercrime/online-scams-or-fraud/.
90. Australian Federal Police, ‘Online fraud and scams’, www.afp.gov.au/policing/cybercrime/online-fraud-and-scams.
91. Association of Certified Fraud Examiners 2014, Report to the nations on occupational fraud and abuse: 2014 global fraud
study, www.acfe.com/rttn/docs/2014-report-to-nations.pdf.
92. PwC 2014, Global economic crime survey 2014, www.pwc.com/gx/en/economic-crime-survey/.
93. Smith, RG, Jorna, P, Sweeney, J & Fuller, G 2014, Counting the costs of crime in Australia: a 2011 estimate, Research and
Public Policy series no. 129, Australian Institute of Criminology, Canberra.
94. PwC 2014, op. cit.
95. Greenwood, E 1957, ‘Attributes of a profession’, Social Work, vol. 2, no. 3, pp. 45–55; Klegon, D 1978, ‘The sociology of
professions: an emerging perspective’, Sociology of Work and Occupations, vol. 5, no. 3, pp. 259–83.
96. PwC 2014, US cybercrime: rising risks, reduced readiness — Key findings from the 2014 US State of Cybercrime Survey,
www.pwc.com/en_US/us/increasing-it-effectiveness/publications/assets/2014-us-state-of-cybercrime.pdf.
97. Association of Certified Fraud Examiners 2014, op. cit.
98. ibid.
99. See www.scamwatch.gov.au/.
100. See www.scamwatch.gov.au/report-a-scam.
101. Stajano, F & Wilson, P 2011, ‘Understanding scam victims: seven principles for system security’, Communications of the
ACM, vol. 54. no. 3, March 2011.
102. Pimple, KD 2011, ‘Computing ethics surrounded by machines’, Communications of the ACM, vol. 54, no. 3, March.
103. Porter, M & Heppelmann, J 2014, ‘How smart, connected products are transforming competition’, Harvard Business Review,
vol. 92, no. 11, pp. 64–88.
104. Montresor, F 2014, ‘14 tech predictions for our world in 2020’, 26 August, https://agenda.weforum.
org/2014/08/14-technology-predictions-2020/.
105. ibid.
106. NSW Police, ‘Fraud and scams’, www.police.nsw.gov.au/community_issues/fraud_prevention.
107. ibid.
108. ibid.
109. ibid.
110. ibid.
111. ibid.
112. ibid.
113. ibid.
114. Australian Federal Police, op. cit.
115. ibid.
116. ibid.
117. ibid.

CHAPTER 14 Ethics and cybercrime 665

ACKNOWLEDGEMENTS
Figure 14.1: © Commonwealth of Australia.
Figure 14.2: www.internetworldstats.com / Copyright © 2001–2015, Miniwatts Marketing Group.
All rights reserved worldwide.
Photo: © racorn / Shutterstock.com.

666 PART 4 Systems issues

 WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.