Recording and Evaluating Systems: Narratives, Flowcharts, and Questionnaires

Learning objectives

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

• Produce a clear system narrative for a business process, highlighting where controls operate and what evidence should exist.
• Draft a simple flowchart that shows the movement of documents, data, and authorisations through a process.
• Use a questionnaire to assess whether control design addresses key risks, including application and general IT controls that support reliability.
• Identify control deficiencies and suggest practical improvements, including compensating controls where constraints exist.
• Use system understanding to shape audit planning decisions by adjusting the nature, timing, and extent of audit procedures.

Overview & key concepts

The ability to record and evaluate systems is essential in audit and finance roles. Many business processes are easy to describe informally (“we raise an order, receive goods, then pay the supplier”), but professional work requires the process to be documented in a form that can be assessed, challenged, and linked to financial reporting risks.

System documentation helps you to:

• understand how transactions are initiated, approved, processed, recorded, and reported
• identify where errors or fraud could arise (and whether controls reduce that risk)
• design audit work efficiently by focusing on areas most likely to contain misstatements

Three practical tools are commonly used together:

• System narratives(written descriptions)
• Flowcharts(visual maps of steps and document/data flows)
• Questionnaires(structured prompts to evaluate whether controls address key risks)

These tools are not part of published financial statements. They are typically used for internal governance and, in an audit context, form part of the auditor’s documentation and working papers.

System narratives

A system narrative is a structured written description of how a process operates from start to finish. It normally sets out:

• who performs each activity (roles and responsibilities)
• what documents or data are created and used
• what authorisations and checks occur
• how transactions are recorded (including interfaces into the ledger)
• how exceptions are identified and resolved

A good narrative is not a story: it is a clear, step-by-step description written so that another person could follow the process and perform a walkthrough. In practice, a walkthrough also records what was observed (documents, screens, approvals) and how the auditor confirmed the flow (enquiry, inspection, and limited re-performance).

What a narrative is for

• to identify points where misstatements could arise (for example, recording purchases not received, or paying invalid suppliers)
• to locate controls (authorisations, matching procedures, reconciliations, reviews)
• to understand what evidence should exist to demonstrate control operation (signatures, system approvals, logs, exception reports)

Flowcharts

A flowchart presents the process visually. It is particularly useful for:

• showing sequence (what happens first, next, and last)
• showing handoffs between departments or systems
• showing where documents and data flow
• spotting weaknesses caused by poor segregation or missing checks

A simple flowchart is usually enough for exam and practice purposes. The goal is clarity rather than artistic complexity.

Good flowchart habits

• keep symbols consistent (process step, decision point, document, data store)
• show ownership: make it obvious who performs each step
• useswimlanes(separate lanes for departments/roles) where possible, as a quick way to show segregation and handoffs
• label control points clearly (for example, “Manager approval” or “Invoice matched to order and receipt”)
• show exception paths (what happens if a match fails, or if approval is declined)

Questionnaires

A questionnaire is a structured set of prompts that helps assess whether controls are appropriately designed to address key risks. It is commonly used to ensure coverage and consistency across processes.

Well-designed questions focus on:

• control objectives (what the process needs to achieve)
• key risks (what could go wrong that matters to financial reporting)
• control features (authorisation, completeness checks, accuracy checks, reconciliations, access controls)
• evidence (how the control is demonstrated in practice)

Questionnaires are not a substitute for understanding. They work best when used after you can already describe the process and identify risk points.

Control objectives and key controls

A control objective is the result the control environment should achieve within a process. Examples in a purchases process include:

• purchases are recorded only when they relate to the entity and are supported by evidence
• liabilities are complete and recorded in the correct period
• payments are made only for valid obligations and to valid supplier bank accounts

A key control is one that addresses a significant risk of misstatement and is important to the auditor’s response—typically selected for testing when planning to rely on controls.

Segregation of duties

Segregation of duties reduces risk by ensuring no one person can complete a transaction end-to-end without appropriate challenge. In practice, separate the ability to:

• approve the decision (commit the organisation)
• carry out the activity (place the order, release the payment)
• record it in the accounting records
• review or reconcile the outcome

Independence is most critical for reviews and reconciliations, and for high-risk areas such as cash/bank access and supplier master data. Where full independence is not possible, strengthen review quality, documentation, and management oversight, and focus it on the highest-risk activities.

Control deficiencies and compensating controls

A control deficiency exists where control design (or its operation) is not sufficient to reduce risk to an acceptable level. Deficiencies commonly arise from:

• missing controls (no approval, no reconciliation, no matching)
• poor design (thresholds too high, reviews not sufficiently robust)
• weak evidence (a “review” that leaves no audit trail)
• access issues (users can override controls or change master data without oversight)

A compensating control is an alternative control that reduces risk when the preferred control cannot be implemented. Compensating controls are often detective in nature (for example, independent reviews after the event) and should be:

• performed by an appropriate person with sufficient objectivity
• frequent enough to detect issues promptly
• evidenced clearly (sign-off, review notes, exception resolution)

A practical method for documenting and evaluating systems

Documenting processes

A reliable process description normally follows a consistent method:

1. Define the boundary
   • Where does the process start and end?
   • What triggers it (for example, a purchase request) and what is the final output (for example, a recorded liability and payment)?
2. Identify actors and systems
   • Departments/roles involved
   • Key IT systems, spreadsheets, and interfaces
3. List inputs and outputs
   • Inputs: purchase requests, approved supplier lists, budgets, contracts
   • Outputs: purchase orders, receipt records/GRNs, invoices posted, payment files, ledger entries
4. Write the sequence
   • Use short, precise steps
   • Highlight authorisations and checks
   • Include exception handling and follow-up

System documentation supports reliable accounting because it clarifies how transactions should be initiated, processed, and recorded. It does not replace the need to apply correct recognition, measurement, and double-entry recording; instead, it helps ensure transactions are captured completely and accurately.

Creating flowcharts

When building a flowchart:

• start with the trigger (for example, “Purchase request raised”)
• show each step in the order performed
• include decision points (approval required? match successful?)
• show documents/data created (PO, receipt record/GRN, invoice, payment run)
• show who performs the step (ideally using swimlanes for departments/roles)

A flowchart is most useful when it makes control points obvious—either by labelling them or positioning them where they prevent or detect errors.

Evaluating control design

Control design evaluation asks a practical question:

If the control were performed exactly as described, would it reduce the key risk meaningfully?

This evaluation typically considers:

• whether the control addresses a specific risk clearly
• whether it is performed by an appropriate person (and sufficiently objective where needed)
• whether it happens at the right time (preventive versus detective)
• whether there is a reliable evidence trail
• whether the control can be bypassed or overridden without visibility

How to spot control deficiencies in practice

Control deficiencies are easiest to identify by comparing:

• what the process needs to achieve (control objectives), with
• what the system actually does (controls present, who performs them, and what evidence exists)

Common diagnostic prompts include:

• Where could a transaction be initiated or changed without approval?
• Where could a transaction be recorded without a supporting document trail?
• Are exception reports produced, reviewed, and followed up?
• Are reviews sufficiently robust and evidenced?
• Can users override controls or amend master data without logging and oversight?

Proposing improvements

Improvements should be practical and proportionate. Strong proposals are:

• directly linked to a stated deficiency and risk
• realistic for the size and complexity of the entity
• clear about who performs the control and what evidence will exist
• targeted at the point in the process where the risk arises

Where ideal segregation is not possible, suggest compensating controls with clear evidence requirements and targeted oversight of the highest-risk activities.

Linking system understanding to audit planning

System understanding informs:

• risk assessment(where material misstatement could arise)
• whether controls testing is efficient(and which controls are key)
• how substantive procedures should be shaped(nature, timing, extent)

If key controls are suitably designed and evidence of operation is expected to be strong, it may be efficient to test controls and adjust substantive procedures accordingly. Reliance on controls typically reduces the extent of detailed substantive testing and may shift timing, but it does not eliminate substantive work altogether.

Linking risks and controls to assertions

When evaluating a process, it helps to connect risks and controls to common financial statement assertions:

• Occurrence/validity:recorded transactions are genuine and relate to the entity
• Completeness:all relevant transactions and balances are captured
• Accuracy:amounts are correctly calculated and recorded
• Cut-off:transactions are recorded in the correct period
• Classification:transactions are recorded in the correct account/category
• Rights and obligations:assets and liabilities represent the entity’s rights/obligations

For purchases and payables, the highest-risk assertions are often completeness and cut-off (unrecorded liabilities), alongside occurrence and accuracy (invalid purchases, incorrect amounts, or payment diversion).

Worked example

Scenario (risk-first lens)

A medium-sized importer uses an integrated purchasing and inventory system with automated invoice capture. Orders are usually raised through the system, but urgent spend is sometimes made using corporate cards and later coded to the ledger. Supplier master data is maintained centrally, and payment files are uploaded to online banking. Management wants comfort that liabilities are complete at period end and that supplier changes cannot be used to divert payments.

The process is intended to work as follows:

1. A department raises a purchase request including quantity, suggested supplier, and budget code.
2. A purchasing officer creates a purchase order (PO) after confirming supplier terms.
3. A manager approves POs above a stated threshold.
4. Goods received are checked against the PO; a goods received note (GRN) is created.
5. Accounts payable performs anagreement checkbefore posting by comparing supplier invoice details to the PO and GRN.(This “agreement check” is the matching of order, receipt and invoice data.)
6. Approved invoices are posted to the purchases ledger; payment runs are authorised by a senior manager.
7. Bank payments are reconciled to the bank statement by someone independent of payment processing.

Required

• Document the purchases process using a system narrative.
• Create a flowchart illustrating the purchases process.
• Evaluate the design of controls using a questionnaire.
• Identify control deficiencies and propose improvements.
• Link system understanding to audit planning decisions.

Solution

1) System narrative (focused on control points and evidence)

The process begins when a department identifies a need for goods or services and raises a purchase request stating quantity, supplier suggestion, and budget code. The purchasing officer reviews the request, confirms commercial terms with the supplier as needed, and raises a purchase order (PO) in the purchasing system. POs above the specified threshold are routed for manager approval before being issued to the supplier. Evidence is retained through system approval records and the approved PO.

When goods are delivered (or services are confirmed as received), receiving staff check the delivery against the PO and create a goods received note (GRN). Any discrepancies (short delivery, damaged items, or delivery without a valid PO) are recorded and followed up with purchasing before acceptance.

Supplier invoices are captured and routed to accounts payable. Accounts payable performs an agreement check by comparing the invoice details to (i) the authorised PO and (ii) the GRN. Invoices that do not agree are placed on hold and investigated. Only invoices that successfully match (or have an approved exception) are posted to the purchases ledger. Evidence is retained through match status reports, hold/exception logs, and posting records.

Urgent corporate card spend is recorded based on card statements and supporting receipts. Coding and approval are documented, and spend is reviewed to ensure it is appropriately classified and complete.

Periodically, accounts payable prepares a payment run based on due dates and approved invoices. A senior manager reviews the payment proposal (supplier, amounts, and unusual items) and authorises release of payments. Payment authorisation is evidenced through system approval or signed payment reports, depending on the platform used.

An independent person—who does not prepare or authorise payments—performs a bank reconciliation by matching ledger movements and payment listings to the bank statement. Reconciling items are investigated and resolved, with evidence of review retained (sign-off and follow-up notes).

2) Linear flowchart (text version suitable for exam conditions)

Start
→ Department raises purchase request
→ Purchasing officer creates PO
→ Decision: PO above approval threshold?
 • Yes → Manager approves PO → PO issued
 • No → PO issued
→ Goods/services received
→ Receiving checks against PO and prepares GRN
→ Supplier invoice captured and routed to accounts payable
→ Agreement check (match PO + GRN + invoice)
→ Decision: Agreement successful?
 • Yes → Post invoice to purchases ledger
 • No → Hold invoice and investigate/resolve exception
→ Payment run prepared (approved invoices only)
→ Senior manager authorises payment run
→ Bank payment released
→ Independent bank reconciliation performed and reviewed
→ Corporate card spend (where used): statement received → receipts matched → coding/approval → post to ledger
End

3) Questionnaire (design-focused)

Supplier master data and payment security

Are changes to supplier bank details verified independently (for example, call-back using a trusted number, or separate approval by an independent person)?

Purchase authorisation and completeness

Are purchase orders required for all purchases, and are exceptions monitored and approved?

Reconciliations and review

Is there evidence that bank reconciliations are prepared promptly and reviewed by an appropriate person with sufficient objectivity?

Application controls (within the process/system)

Does the system enforce approval workflows and matching rules (for example, preventing posting where the agreement check fails unless an authorised override is applied)?

General IT controls (supporting the reliability of system processing and audit trails)

Are access rights restricted for high-risk actions (supplier master data amendments, override permissions, payment release), and are audit logs monitored?

4) Control deficiencies and improvements

Deficiency A: Supplier bank detail changes not independently verified

• Risk:Payments may be diverted to an incorrect or fraudulent account, leading to loss and misstated expenses/cash.
• Improvement (primary control):Restrict bank detail changes to nominated users and require independent verification/approval before changes become active.
• Improvement (supporting controls):Weekly report of supplier bank amendments reviewed with evidence of follow-up and resolution.

Deficiency B: PO bypass for urgent low-value items with no monitoring

• Risk:Purchases may be unauthorised, incorrectly coded, duplicated, or omitted from liabilities at period end (completeness/cut-off risk).
• Improvement:Introduce a controlled exception route requiring documented reason, after-the-event approval, and periodic management reporting on exception volume/value.

Deficiency C: Override and master data activity not monitored (IT/audit trail weakness)

• Risk:Overrides or supplier amendments could enable invalid invoices or payment diversion without timely detection.
• Improvement (primary control):Limit override permissions to nominated users and require documented approval for overrides above defined tolerances.
• Compensating control:Independent monthly review of audit logs/reports covering overrides, supplier amendments, and payments to new/changed bank accounts, evidenced by sign-off and exception resolution.

Deficiency D: Segregation risk around supplier maintenance and payments (where roles overlap)

• Risk:If a single individual can amend supplier data and also prepare or authorise payments, the opportunity for fraudulent payments increases materially.
• Improvement:Separate permissions so supplier master data maintenance, invoice posting, and payment authorisation cannot be performed by the same user. Where full separation is not feasible, strengthen management oversight and focus review on supplier changes and payment releases, with clear evidence.

5) Linking to audit planning decisions

This process understanding highlights key risk areas in purchases, payables, and cash, and whether controls reduce those risks.

• Where controls appear well designed and evidenced(for example, consistent agreement checks with system logs and robust bank reconciliation review), controls testing may be efficient and can support reducing the extent of some detailed testing and/or adjusting timing. Substantive procedures, however, still remain necessary in many areas and are tailored rather than removed.
• Where controls are weak or not reliably evidenced(for example, unverified bank detail changes, uncontrolled exceptions, or unmonitored overrides), the audit approach typically increases substantive procedures. This may include enhanced payables completeness and cut-off work, detailed testing of payments to new or amended supplier accounts, and expanded procedures over corporate card spend classification and authorisation.

Interpretation of the results

The narrative, flowchart, and questionnaire convert an informal description into documentation that can be evaluated. Together they clarify:

• where transactions enter the accounting records
• where controls are expected to prevent or detect misstatements
• what evidence should exist to demonstrate control operation
• where weaknesses increase the likelihood of error or fraud

In this scenario, strong features include independent bank reconciliation and an agreement check before invoice posting (where consistently applied and evidenced). Significant weaknesses relate to supplier bank detail security, unmanaged exceptions to PO requirements, and insufficient oversight of high-risk system actions (overrides and master data changes). These weaknesses increase misstatement risk and influence both audit strategy and detailed procedure design.

Common pitfalls and misunderstandings

• Narratives that are too vague:A narrative should specify who does what, what evidence exists, and how exceptions are handled.
• Treating documentation as proof:Documentation describes what should happen; walkthroughs and testing confirm what actually happens.
• Flowcharts without ownership:If roles are not shown (ideally via swimlanes), segregation issues are easy to miss.
• Ignoring exception routes:Many failures occur in overrides, urgent purchases, unmatched invoices, or manual adjustments.
• Confusing design and operation:A control can look strong on paper but fail in practice if not performed consistently or evidenced.
• Unrealistic improvements:Recommendations should be proportionate and workable.
• Overlooking compensating controls:If ideal segregation is not feasible, propose targeted oversight with clear evidence.
• Weak audit linkage:Control findings should lead to a clear adjustment in audit focus and procedure design, not a generic statement that “more testing is needed.”

Summary and further reading

Documenting and evaluating systems is essential for understanding how transactions are processed and where financial reporting risks arise. System narratives, flowcharts, and questionnaires work best as a set: the narrative explains, the flowchart visualises, and the questionnaire tests design against key risks.

Effective documentation supports risk assessment and helps shape audit planning decisions—whether controls testing is efficient and how substantive procedures should be tailored (nature, timing, and extent).

For further reading, use introductory texts on internal control, audit planning, and business process documentation, alongside high-level guidance on governance and financial reporting risk.

FAQ

What is the primary purpose of a system narrative?

A system narrative documents how a process operates from start to finish, identifying roles, documents/data, key steps, control points, and exception handling. Its main purpose is to support understanding of transaction flow, highlight risk points, and show where controls are expected to prevent or detect errors and fraud.

How do flowcharts complement system narratives?

A flowchart shows the process visually, making sequence, handoffs, and control points easier to see. Using ownership (and swimlanes where possible) helps reveal segregation weaknesses and areas where steps can be bypassed.

Why are questionnaires important in evaluating control design?

Questionnaires provide structured coverage of common risk areas and control features. They help ensure you consider authorisation, completeness, accuracy, access restrictions, audit trails, and review—especially in areas where weaknesses are easy to overlook.

What are the consequences of failing to identify control deficiencies?

If deficiencies are missed, errors or fraud may go undetected, increasing the risk of misstated financial information. It can also lead to ineffective audit planning, with insufficient work in high-risk areas or unnecessary work in low-risk areas.

How does system documentation impact audit planning?

System documentation helps identify where misstatements could occur and whether controls reduce those risks. Strong, well-evidenced controls may support efficient controls testing and a tailored substantive approach. Weak or poorly evidenced controls generally push the audit strategy towards more extensive substantive procedures.

Summary (Recap)

This chapter covered how to document and evaluate systems using narratives, flowcharts, and questionnaires. It explained control objectives and key controls, segregation of duties, how to diagnose control deficiencies, and how to propose practical improvements including compensating controls. The worked example illustrated a purchases process in a modern environment and showed how system understanding shapes audit planning by influencing the balance between controls testing and the design of substantive procedures.

Glossary

System narrative
A structured written description of how a process operates, including roles, documents/data, key steps, control points, and exception handling.

Flowchart
A visual map of a process showing activities, decision points, documents/data flows, and handoffs between people or systems.

Swimlanes
Separate lanes within a flowchart (typically by department or role) used to show ownership of steps and highlight handoffs and segregation.

Questionnaire
A set of structured prompts used to assess whether key controls exist and whether their design addresses significant risks effectively.

Control objective
A specific outcome a process should achieve to manage risk (for example, ensuring only valid liabilities are recorded and paid).

Key control
A control that addresses a significant risk of misstatement and is important to the auditor’s response—typically selected for testing when planning to rely on controls.

Segregation of duties
The separation of end-to-end capability so that approval, execution, recording, and review are not concentrated in one individual without appropriate challenge.

Control deficiency
A weakness in control design or operation that reduces the ability of the system to prevent or detect misstatements.

Compensating control
An alternative control that reduces risk when the preferred control cannot be implemented, often through targeted oversight and exception reporting.

Application controls
Controls built into a process or system that help ensure transactions are authorised, complete, and accurately processed (for example, automated approvals, matching rules, tolerance limits).

General IT controls
Controls that support the overall reliability of systems and data (for example, user access management, change controls, and logging/monitoring).

Design effectiveness
Whether a control, if performed properly, would be capable of preventing or detecting a misstatement.

Operating effectiveness
Whether a control actually worked in practice over a period, performed consistently by appropriate people with reliable evidence.