Business Processes, Documentation and Modelling

Introduction

Accounting information systems (AIS) transform economic events into information used for recording, reporting, control and decision-making. The quality of that information depends not only on software, but also on how business processes are designed, documented and controlled. A poorly understood purchasing process may produce duplicate payments; an inadequately segregated sales process may permit fictitious customers or unauthorized discounts; and an incomplete system model may conceal where data are altered or lost.

Business-process analysis provides a disciplined way to understand how an organisation receives inputs, performs activities, makes decisions, produces outputs and exercises control. In accounting, this analysis supports transaction processing, audit planning, internal-control evaluation, system acquisition, process improvement and compliance.

This chapter examines narratives, document flowcharts, system flowcharts, data-flow diagrams (DFDs), business process models and segregation-of-duties matrices. These tools are complementary rather than interchangeable. A narrative explains the process in words; a flowchart shows sequence and movement; a DFD focuses on data transformation and storage; a business process model represents events, activities, participants and decisions; and a segregation-of-duties matrix evaluates whether incompatible responsibilities are assigned to different people or controls.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the role of business processes in an AIS.
2. Prepare and evaluate process narratives.
3. Construct and interpret document flowcharts and system flowcharts.
4. Develop context-level and lower-level DFDs using balancing and decomposition principles.
5. Use business process modelling concepts to represent events, activities, decisions and participants.
6. Prepare a segregation-of-duties matrix and identify control weaknesses.
7. Evaluate documentation for completeness, accuracy, clarity, control visibility and maintainability.
8. Recommend improvements while considering technology, governance, ethics and operational risk.

1. Business Processes and the Accounting Information System

A business process is a connected set of activities that converts inputs into outputs for a customer, manager, regulator or another process. Examples include the revenue cycle, expenditure cycle, payroll cycle, production cycle and financial reporting process.

An AIS captures transaction data, processes it according to authorised rules, stores records and produces information. A process view is important because accounting entries rarely arise from isolated actions. A credit sale, for example, begins with a customer order, involves credit approval and dispatch, produces an invoice, updates receivables and inventory, and ultimately affects cash collection and financial reporting.

A process can be analysed through five questions:

• What triggers the process?
• Who performs each activity?
• What documents or data are created, used or changed?
• What controls reduce the risk of error, fraud or non-compliance?
• What outputs result, and who uses them?

Process characteristics

A well-defined process has a purpose, identifiable boundaries, inputs, activities, outputs, participants and controls. Process boundaries are especially important. If the analysis begins too late, the source of an error may be missed; if it ends too early, the accounting or control consequences may not be visible.

Processes also have owners. A process owner is accountable for performance and improvement, although individual activities may be performed by several departments. Useful performance dimensions include accuracy, timeliness, cost, compliance, customer service, security and reliability.

Major AIS cycles

2. Documentation as an Accounting and Control Activity

Documentation creates an organised representation of how work is performed. It supports training, communication, audit evidence, system development, accountability and continuity when employees change roles. Documentation is also a control: when responsibilities and required evidence are explicit, unauthorised activity is more difficult to conceal.

Good documentation should be:

• Complete: all relevant activities, inputs, outputs, exceptions and controls are included.
• Accurate: the representation agrees with actual practice and approved policy.
• Clear: symbols, labels and terminology are understandable.
• Consistent: the same symbol and name have the same meaning throughout.
• Traceable: transactions can be followed from source document to ledger and report.
• Maintained: changes in systems, roles or regulations are reflected promptly.

A critical distinction is between an as-is model, which describes current practice, and a to-be model, which describes a proposed future state. Treating a to-be model as if it were current can cause auditors, developers or managers to rely on controls that do not yet exist.

3. Process Narratives

A process narrative is a structured written description of activities, participants, documents, systems, decisions and controls. It is often the first documentation prepared because interviews and observation usually generate verbal information before formal diagrams are drawn.

A useful narrative identifies:

1. Process purpose and boundaries.
2. Triggering event and frequency.
3. Departments, roles and systems involved.
4. Sequential activities.
5. Documents and data used or produced.
6. Authorisations and review points.
7. Exception paths.
8. Records retained and final outputs.

Example narrative: purchase-to-pay

In this illustrative process, a department employee identifies a need for goods and submits an electronic purchase requisition. The procurement department reviews the requisition and selects an approved supplier. A purchase order is issued only after approval within the employee’s delegated authority. The receiving department independently compares delivered goods with the purchase order and records a receiving report. The supplier sends an invoice to accounts payable. Accounts payable performs a three-way match between the purchase order, receiving report and invoice. Matched invoices are included in a payment batch approved by the finance manager. The payment system transfers funds, updates the accounts-payable subsidiary ledger and posts the transaction to the general ledger. Unmatched items are placed on hold and investigated.

This narrative reveals several controls: approval of requisitions, use of approved suppliers, independent receiving, three-way matching, payment approval and reconciliation. It also identifies an exception route rather than describing only the normal path.

Narratives are particularly useful when processes are complex, when interview evidence must be preserved, or when explaining a diagram to a non-specialist. Their weakness is that long prose can conceal sequence, parallel activities and responsibility changes. For this reason, narratives are commonly combined with visual models.

4. Document Flowcharts and System Flowcharts

A flowchart uses standard symbols to represent activities, documents, data, storage and movement. Conventions vary slightly, so an organisation should maintain a symbol legend. Consistency is more important than adherence to one stylistic variant.

Document flowcharts

A document flowchart emphasises physical or electronic documents and the departments through which they move. Columns or swim lanes usually represent organisational units. A document flowchart can show where a purchase order is created, where a receiving report is retained and where an invoice is routed for approval.

Its principal uses are:

• tracing source documents through the organisation;
• identifying duplicate data entry;
• locating missing approvals or records;
• examining custody and authorisation;
• evaluating segregation of duties.

A document flowchart should distinguish original documents from copies, show document destinations and identify whether a document is manually prepared or system-generated.

System flowcharts

A system flowchart represents the relationship among inputs, processing steps, files or databases, outputs and controls. It may include both manual and computerised operations. Compared with a document flowchart, it focuses more strongly on information-processing procedures and technology.

A system flowchart can show that a scanned invoice enters an accounts-payable application, is validated against master data and purchase records, is stored in an invoice database, and produces an exception report or payment file. It should make visible interfaces between systems, batch or real-time processing, automated validation and points where human intervention remains necessary.

Flowchart evaluation

When evaluating a flowchart, ask whether:

• every input has a source and every output has a destination;
• arrows show direction clearly and do not cross unnecessarily;
• decisions have labelled alternatives, such as “yes” and “no”;
• manual and automated activities are distinguishable;
• controls are shown at the point where they operate;
• exception and rework paths are represented;
• the level of detail is appropriate for its audience.

A flowchart is not automatically correct because it looks professional. It must be validated through observation, document inspection, system demonstrations and discussion with process participants.

5. Data-Flow Diagrams

A DFD models the movement and transformation of data rather than the physical movement of documents or the detailed sequence of tasks. Its four fundamental elements are:

• External entity: a person, organisation or system outside the boundary that sends or receives data.
• Process: an activity that transforms input data into output data.
• Data flow: a named movement of data.
• Data store: a repository from which data may be read or to which data may be written.

A context diagram presents the entire system as one process and shows its major external entities and data flows. A level-0 DFD decomposes the system into major processes and data stores. Further levels provide additional detail.

DFD rules

A DFD should obey several principles:

1. Every process should have at least one input and one output. A process with outputs but no inputs may be a data source incorrectly omitted from the model; a process with inputs but no outputs may be a sink that requires investigation.
2. Data should not flow directly from one external entity to another without a process inside the system boundary.
3. Data should not flow directly from one data store to another without a process.
4. Data should not flow directly between an external entity and a data store without a process.
5. Data-flow names should describe data, not actions. “Approved invoice” is preferable to “approve invoice.”
6. A lower-level diagram must balance with its parent diagram: inputs entering and outputs leaving the decomposed process must remain consistent.

Balancing does not require every internal data flow to appear on the higher-level diagram. It requires the external inputs and outputs of the parent process to be preserved.

DFD versus flowchart

A DFD does not normally show the order in which activities occur, the responsible employee, or whether processing is manual or automated. A flowchart can show those features. Conversely, a DFD is often better for defining system scope, interfaces and data requirements. Confusing these models can produce diagrams that are neither semantically precise nor operationally useful.

6. Business Process Modelling

Business process modelling uses a controlled notation to represent events, activities, participants, decisions, messages and outcomes. Business Process Model and Notation (BPMN) is widely used because it provides a common language for business and information-technology professionals.

Common BPMN concepts include:

• Pools: separate organisations or independent participants.
• Lanes: roles or departments within a participant.
• Start events: conditions that initiate a process.
• Tasks: work performed by a person or system.
• Gateways: points at which paths diverge or converge.
• End events: completion or termination outcomes.
• Sequence flows: order of activities within a participant.
• Message flows: communication between separate participants.

A gateway should represent a meaningful decision or synchronisation. For example, after invoice matching, an exclusive gateway may direct the invoice either to payment approval or to an exception queue. A parallel gateway may show that inventory and accounting records are updated concurrently, provided that the system actually supports parallel execution.

BPMN is useful for analysing hand-offs, waiting time, exception management and automation opportunities. It can also expose a control problem: if the same lane performs supplier creation, invoice approval and payment release, the model makes the concentration of authority visible.

7. Segregation of Duties and Control Analysis

Segregation of duties (SoD) is an internal-control principle requiring incompatible responsibilities to be assigned to different individuals or controlled through compensating mechanisms. The traditional incompatible functions are:

1. Authorisation: approving a transaction or decision.
2. Custody: possessing assets or controlling access to them.
3. Recording: entering or maintaining accounting records.
4. Reconciliation or review: comparing records, investigating differences and monitoring compliance.

No single separation rule is universally sufficient. The appropriate design depends on transaction volume, system access, staff size, risk, regulation and the availability of independent review.

Segregation-of-duties matrix

A matrix lists roles on both axes and identifies combinations that create risk. For example, a cell may indicate that a person who can create suppliers should not also be able to release payments. The matrix should be based on actual permissions, not merely job titles.

The matrix is a risk-screening tool, not a substitute for judgement. “High risk” means that combined access could enable or conceal an inappropriate transaction; it does not prove that misconduct has occurred.

Where full SoD is impractical, compensating controls may include independent review of exception reports, owner approval of supplier changes, payment thresholds, dual authorisation, bank statement review, access logging and periodic user-access recertification.

8. Integrated Applied Case: Northbridge Office Supplies

This is an illustrative case. Northbridge Office Supplies operates three branches. Each branch can create suppliers, approve purchases up to a local limit and record goods received. The central finance team records invoices and releases electronic payments. A recent internal audit found duplicate payments and several suppliers sharing bank-account details.

Background and problem

The existing procedure was described in a two-page narrative, but it did not include supplier-master changes, exception handling or the relationship between branch systems and the central ledger. The document flowchart showed invoices moving to finance but did not identify who approved payment. Access reports showed that one finance employee could create suppliers, enter invoices and release payments.

Analysis

The audit team first prepared an as-is narrative through interviews, observation and inspection of system logs. A document flowchart identified the movement of requisitions, purchase orders, receiving reports and invoices. A DFD clarified that branch systems sent purchase and receipt data to the central finance system, while supplier-master data could be changed centrally without branch notification. A BPMN model exposed a bypass: invoices with a missing purchase order could be manually entered and paid after an informal email approval.

The SoD matrix identified three high-risk combinations:

• supplier creation with payment release;
• invoice entry with payment release;
• supplier-bank-detail changes with bank reconciliation.

Approach and solution

Northbridge implemented the following changes:

1. Supplier creation and bank-detail changes were assigned to a procurement master-data team.
2. Changes required documented approval and independent callback verification using a trusted supplier contact.
3. Invoice matching became mandatory for standard purchases; exceptions required finance-manager approval and a coded reason.
4. Payment files required dual electronic authorisation.
5. A weekly report identified duplicate invoice numbers, duplicate bank accounts and unusual payment patterns.
6. Bank reconciliations were assigned to staff who could not release payments.
7. The documentation was version-controlled, with an owner, review date and change history.

Outcome

The redesigned process improved traceability and made incompatible access visible. Duplicate-payment alerts were generated before release, and exception transactions could be reviewed separately from routine transactions. The solution did not eliminate risk: supplier collusion, compromised credentials and poor review could still cause loss. However, risk was reduced through preventive, detective and corrective controls.

Learning points

The case illustrates why no single model is adequate. The narrative captured policy and exceptions; the document flowchart showed custody and departmental movement; the DFD clarified data interfaces; BPMN showed decisions and hand-offs; and the SoD matrix evaluated conflicting access. Together, these tools supported a defensible control redesign.

9. Technology, Governance and Ethical Considerations

Contemporary AIS environments use enterprise resource planning systems, application programming interfaces, cloud platforms, robotic process automation and data analytics. These technologies can reduce manual entry and enforce rules, but automation does not remove control responsibility. An automated workflow may apply an incorrect rule consistently, and an interface may transmit unauthorised or incomplete data at high speed.

Artificial intelligence may assist with document classification, invoice matching, anomaly detection and process mining. Professional judgement remains essential because models can produce false positives, miss novel fraud patterns or reflect biased historical data. Organisations should document model purpose, data sources, validation procedures, confidence thresholds, human review and override decisions.

Governance requirements include access control, audit trails, retention, privacy, cybersecurity, change management and regulatory compliance. Documentation should show who approved a system change, what logic changed, when it became effective and how the change was tested. Personal data should be collected and disclosed only for legitimate purposes and protected against unauthorised access.

Ethically, accountants and system designers should not conceal exceptions, manipulate process models to make controls appear stronger than they are, or treat a diagram as evidence that an activity actually occurs. Models must represent reality honestly, including inconvenient manual workarounds and control failures.

10. Best Practices and Limitations

Effective modelling usually follows a cycle:

1. Define scope, purpose, audience and model type.
2. Gather evidence from interviews, observation, documents, configurations and logs.
3. Draft the current-state narrative and model.
4. Validate the draft with process participants.
5. Identify risks, bottlenecks, rework, data duplication and incompatible access.
6. Design the future state and controls.
7. Obtain approval and assign ownership.
8. Test the implemented process and update documentation.

Important limitations should be acknowledged. Interviews may reflect what staff believe should happen rather than what actually happens. A model may become obsolete after a software release or organisational change. Excessive detail can make a model unreadable, while insufficient detail can hide control gaps. Standard notations improve communication but do not guarantee correct analysis. Finally, SoD may be difficult in small organisations, where compensating controls must be designed and tested carefully.

Chapter Summary

Business processes connect operational events with accounting records, information outputs and internal controls. Documentation is both a communication mechanism and a control because it defines responsibilities, evidence and required actions. Narratives explain activities and exceptions in words. Document flowcharts focus on the movement and custody of documents; system flowcharts show processing, files, interfaces and outputs; DFDs represent data movement and transformation; and BPMN models participants, events, activities, decisions and messages. These approaches answer different questions and should be integrated rather than confused.

Segregation-of-duties analysis examines whether authorisation, custody, recording and review are appropriately separated. A matrix identifies risky combinations, while compensating controls may reduce risk when complete separation is impractical. Reliable analysis requires evidence, validation, version control and attention to technology, privacy, cybersecurity, ethics and governance. The ultimate purpose of modelling is not diagram production; it is improved understanding, accountability, control and informed process improvement.

Key Terms

Business process: Connected activities that transform inputs into outputs.

Process owner: Person accountable for process performance and improvement.

Narrative: Written description of activities, participants, data, documents and controls.

Document flowchart: Diagram showing document movement among organisational units.

System flowchart: Diagram showing inputs, processing, storage, outputs and system interfaces.

Data-flow diagram: Model of data movement, transformation, external entities and data stores.

Context diagram: Highest-level DFD showing the system and its external interfaces.

Balancing: Maintaining consistent external inputs and outputs across DFD levels.

BPMN: Standard notation for modelling business-process events, activities and participants.

Pool: BPMN representation of an independent participant.

Lane: BPMN subdivision representing a role, department or responsibility.

Gateway: Decision or synchronisation point in a process model.

As-is model: Representation of the current process.

To-be model: Representation of a proposed future process.

Segregation of duties: Separation of incompatible responsibilities.

Authorisation: Approval of a transaction or decision.

Custody: Physical or logical control over assets or access.

Compensating control: Control that reduces risk when a primary control is impractical.

Three-way match: Comparison of a purchase order, receiving report and supplier invoice.

Process exception: Transaction or condition that does not follow the standard path.

Review Questions

Short Answer Questions

1. What are the main purposes of documenting an accounting process?
2. Distinguish a document flowchart from a data-flow diagram.
3. What is meant by balancing in a DFD?
4. Identify the four traditional functions considered in segregation-of-duties analysis.
5. Why should exception paths be included in process documentation?

Long Answer Questions

1. Explain how narratives, flowcharts, DFDs and BPMN models complement one another in AIS analysis.
2. Describe the rules for constructing a context diagram and a balanced lower-level DFD.
3. Explain how a purchase-to-pay process can be designed to reduce duplicate payments and unauthorised suppliers.
4. Discuss the benefits and limitations of segregation-of-duties matrices.
5. Evaluate the governance and ethical risks associated with AI-supported invoice processing.

Analytical / Application Questions

1. A finance employee can create suppliers, enter invoices and release payments. Prepare a risk analysis and recommend preventive, detective and compensating controls.
2. Construct a context-level DFD for a payroll system, identifying external entities, major data flows and the system boundary. Explain how you would validate it.
3. A process model shows that invoices without purchase orders bypass matching after an email approval. Analyse the control weakness and propose an improved to-be process, including an exception route and SoD assignments.

Multiple Choice Questions with Answers

Question 1

Which model primarily focuses on the movement and transformation of data?

A. Document flowchart

B. Data-flow diagram

C. Organisation chart

D. Segregation-of-duties matrix

Correct Answer: B. Data-flow diagram

Question 2

Which activity is most directly associated with custody?

A. Approving a purchase order

B. Recording an invoice

C. Possessing inventory

D. Reconciling the bank account

Correct Answer: C. Possessing inventory

Question 3

What must remain consistent when a DFD process is decomposed into a lower-level diagram?

A. Every internal activity name

B. The number of employees involved

C. The parent process’s external inputs and outputs

D. The physical location of the database

Correct Answer: C. The parent process’s external inputs and outputs

Question 4

What does a BPMN gateway normally represent?

A. A data store only

B. A decision or synchronisation point

C. A supplier master file

D. A financial statement

Correct Answer: B. A decision or synchronisation point

Question 5

Which control is part of a three-way match?

A. Comparing a bank statement with a budget

B. Comparing a purchase order, receiving report and invoice

C. Comparing employee attendance with sales

D. Comparing a trial balance with a forecast

Correct Answer: B. Comparing a purchase order, receiving report and invoice

Question 6

Which combination creates the clearest segregation-of-duties risk?

A. Preparing a report and reading a policy

B. Creating suppliers and releasing payments

C. Receiving training and using a dashboard

D. Reviewing a diagram and attending a meeting

Correct Answer: B. Creating suppliers and releasing payments

Question 7

What is the primary purpose of a context diagram?

A. To show every detailed task in the process

B. To show the system boundary and major external interfaces

C. To assign employee salaries

D. To replace all control testing

Correct Answer: B. To show the system boundary and major external interfaces

Question 8

Which feature makes process documentation more reliable?

A. Describing only the normal path

B. Excluding manual workarounds

C. Validating the model against observation and system evidence

D. Using as many symbols as possible

Correct Answer: C. Validating the model against observation and system evidence

Question 9

If an invoice has no purchase order and is routed for special approval, this is an example of what?

A. A process exception

B. A data store

C. A context diagram

D. A source document original

Correct Answer: A. A process exception

Question 10

Which is an appropriate compensating control when complete segregation is impractical?

A. Removing all audit trails

B. Allowing unrestricted access

C. Independent review of exception reports

D. Using undocumented verbal approvals

Correct Answer: C. Independent review of exception reports