Process Documentation Narrative and Flow Chart Guide

Introduction
Developing an adequate understanding of any processing environment is critical to performing internal audit reviews. This document will describe these techniques, provide a process flow example and guidance on elements to be incorporated. The guide will assist teams as documentation is developed and evaluated during the audit review process.

Documenting an understanding of a process, related controls, and key roles and responsibilities can be achieved through process narratives and flow charts. Both of these documentation techniques assist internal audit teams and those responsible for the processes to establish a common understanding of a process.

Once these documents are confirmed as accurate they provide a baseline for performing risk analysis, internal controls testing, and implementing process improvements as necessary.

Narrative and process flow tools allow auditors to organize, describe, and graphically depict the results of:

• Reviewing policy and procedure manuals;
• Discussing the process with key employees through inquiry;
• Performing a process walk through of sub-processes using samples, etc.
• Considering key inputs and outputs to a process;
• Lines of responsibility for individual employee and departmental roles

The objective of process narratives and flow diagrams is to generate an accurate representation of how work is actually performed. Audit teams are then positioned to add value to recommend improvements, evaluate segregation of duties controls, and identify key controls. View a sample flow map.

Typically, creating this type of documentation is a reiterative process that involves individuals at various levels of responsibility discussing processing steps, related documents and responsibilities, and process metrics or outputs.

For example, an initial overview of a process is be described by a general ledger manager at a high-level. This initial description of the process may be a fair reflection of the actual policies and procedures manual. Then, per discussion with the monthly accrual accounting supervisor, additional details of the procedural inputs may confirm some of procedures pointed out by the general ledger manager and also reflect new detail or key changes to the process. Finally, inquiry and examination of process examples by those performing accrual analysis may reveal key authorization controls, supervisory review, and output schedules not described earlier.

Together, the audit team must condense the process information into manageable narratives and process flows that incorporate all the key steps, processing responsibilities, documents, and actions. Both manual and application-based activities should be included with a focus on key control points and outputs. These will include authorizations, supervisory review, and controls configured in processing applications like access security, segregation of duties through restrictions to processing functionality, and transaction logs.

Risks & Controls
Narratives and process flow maps are designed to assist the analysis of processing risks and related controls. Although these documentation techniques do not test the effectiveness of controls, they should promote an agreed upon understanding of how a process is performed, who performs specific duties (roles and responsibilities), and assertions about control activities.

The control assertions may be part of or linked to the Committee of Sponsoring Organizations (COSO) Integrated Internal Control Framework. For example, the control elements of completeness, accuracy, authorization, safeguarding of assets, and rights/obligations, etc. should be incorporated into processing activities. It may not be critical to include reference to the COSO control elements but the audit team should be mindful that the underlying internal controls incorporated into the processes being documented mitigate associated risk of financial statement misstatement and ensure consistency with GAAP.

Key risks and controls can be mapped on the process flow diagram to indicate when, by whom, and how controls mitigate risks. The example in appendix A utilizes numbered symbols such as small circles and triangles aligned with actual process flow shapes to indicate understanding at a specific junction of the process. These tick marks are different from the normal flow charting shapes that depict a starting/ending point, action/process, document or decision.

Documentation
Documentation typically includes a process summary, detailed process narrative, and a process flow diagram. Microsoft VISIO is a leading tool but other flowchart applications work well.

Each flow diagram should include a legend of shapes used and other explanations. In addition, the diagram will have a list of risks and a separate list of identified controls that correlate to them on the process flow. Also, notice the extended horizontal lines that separate the processing departments included in the overall process. These “swim lanes” depict who is responsible for an action or decision.

Diagrams may extend several pages and cover description in sufficient detail to reflect key processes, documents, risks and controls, and identification of personnel and systems involved.

Process Narrative & Flow Guide

Process Summary:	Yes or No
A) Does the process narrative summary have the preparer’s name?
B) Does the process narrative summary have the approver’s name (where applicable)?
C) Is the process owner name evident on the process narrative summary?
D) Are the relevant policies and procedures (P&P) noted on the summary?
E) Are the P&P in the documentation folder or related application storage facility? Where?
F) Does the summary clearly indicate the financial statement accounts impacted by the process?
G) Does the summary indicate the related COSO assertion (where applicable)?
Process Maps:	Yes or No
A) Is there a defined start symbol (either start or connector from another map)?
B) Does the map have a legend that describes the various shapes in the map?
· Is each shape in the map appropriate (e.g., database reference shows a database shape)?
C) Does each shape (process) describe ->
1) Who is performing the action? Note: Examples include: AP Clerk, Senior Accountant, Controller, etc. This is particularly important when describing authorization/approval controls.
2) Are only position titles (not names) utilized in the map?
3) What action are they performing [e.g., reconciling, posting, validating, etc]?
4) When are they performing the action?
5) Where is the action being performed (could be externally, internally, systemic application, database, etc., different dept, etc.)?
D) How is the action being performed? Note: describe what is being utilized to perform the action - report name, database, etc.
E) Do the maps indicate inputs, outputs for each activity?
F) Is the input/output specifically identified (i.e., exact name of query or name of report)?
G) Have all FINANCIAL risks been identified? Note: What could go wrong for each shape - with a financial impact focus?
H) Have all FINANCIAL controls been identified? Note: How do we prevent what could go wrong such as a mitigating control?
I) Are there any estimates or assumptions in the process?
· Is the methodology explained/documented in the narrative?
J) Does the process end at the end of the map?
Yes - Is there a defined end symbol?
No - Is the next process connector on the map instead of an end symbol?
K) If process map is linked to/from another, have the terminology and common activities been named the same between maps?
L) Have risks been documented where the risk is occurring?
M) Have controls been documented where they occur? Note: controls that occur outside of the process (e.g., senior management operational review) should be documented on the map.
Does every risk identified on the process map have an associated description in the narrative?
N) Does every risk identified on a process step have a control and vice versa?
Information Technology:	Yes or No
A) Is the specific database referenced where process information exists?
B) Does the narrative indicate which database?
C) Have IT processes within each financial/operational process map been identified?
D) Has IT provided process and control information when computer applications are involved? · Are all the applications used listed/represented?
E) If the financial process is dependent on other IT processes (e.g., polling, interfaces, etc.), have these IT processes been identified and linked to the applicable IT map(s)?
F) Has IT provided process and control information when computer applications are involved?
G) Do process flow maps or narratives cite specific application controls and related individual users (position associated with access)?
Note: See the Controls Checklist below for coverage of basic IT control attributes.
Risk Checklist	Yes or No
A) Is the risk defined adequately enough to explain what could go wrong - from a financial reporting perspective only?
B) Have all FINANCIAL risks been identified? Note: Think about what could go wrong for each shape and focus on the financial impact.
C) Does the risk identified collaborate with a COSO assertion?
D) Does every risk have its own number?
E) Does every risk link to at least one control?
F) Does every risk statement contain the cause and effect?
Controls Checklist	Yes or No
Have all FINANCIAL controls been identified? - [How do we prevent what could go wrong?]
Are there any risks/controls that apply to the whole process?
FOR EACH CONTROL:
Does the control list who performed, when in the process/cycle, and how executed?
I. If a restrict access control, does the control detail that the:
a. Access is relevant to job responsibilities.
b. Access is reviewed periodically for appropriateness.
c. Access is appropriately authorized.
II. If an exception report control, does the control detail:
a. What information is contained in the report?
b. Who reviews the report and how often?
c. What follow-up activities are performed for exceptions/errors detected?
d. How are file transfers reviewed for completeness and accuracy?
e. How often do file transfers occur?
f. What system generates the report?
III. If a management review/monitoring control, does the control detail:
a. How often are reports/results reviewed?
b. What is the purpose of the review?
c. Who performs?
d. Follow up procedures for discrepancies/unusual variances?
IV. If a segregation of duties control, does the control detail:
a. Which responsibilities are segregated?
b. How are duties segregated? (view / read-only)
c. Does an organization or department chart exist, and where is it located?
V. If an approval or authorization control, does the control detail:
a. Whether it is manually documented or system driven?
b. Who approves (what level of management?)
c. Existence of an established level of authorization?
VI. If a reconciliation control, does the control detail:
a. Who prepares and performs the reconciliation?
b. What is the purpose of the reconciliation?
c. Who reviews the reconciliation?
d. What is the evidence of the review? ( manager approval)
e. What reports are used and which systems generate the reports used?
f. How are differences investigated / resolved?
VII. If a document control, does the control detail that:
a. Documents are pre-numbered and system generated (e.g., sales orders, invoices etc)
b. Documents are safeguarded (e.g., physical controls over checks, contracts, manual journal entry logs, etc.)?
VIII. If a physical asset control, does the control detail:
a. How is the access to the asset and related record keeping appropriately restricted and is it reviewed periodically?
b. What procedures ensure the accuracy of the related record keeping (activity logs)?
IV. If a system based control, does the control detail:
a. All key fields for data entry must contain valid information (e.g., current date, established dollar range) in order for a record to be accepted.
b. Information is validated against a master table (e.g., customer number, product number, vendor number, PO number).
c. Master tables are reviewed and updated regularly to ensure accuracy and table data is safeguarded.
d. Duplicate postings/entries are not accepted.
e. Accounting period-end cut-off dates are enforced by the system.
f. System-based control overrides must be authorized.
Additional Considerations:
A) Is the methodology explained / documented in the control descriptions for formulas etc?
B) Is the control frequency documented e.g., quarterly, monthly, weekly, daily, multiple times daily?
C) The control description adequately explains how it mitigates the risk?
D) Is the control type (Preventive, Detective, Corrective) listed?
Is the control type listed accurate?
E) Is the control owner listed?
F) Are only position titles (not names) utilized in the RCM?
G) Is the control technique (Systemic, Manual) listed?
Is the control technique listed accurate?
H) Is the control level (Primary, Secondary, Tertiary) listed?
Is the control level listed accurate?
I) Is the COSO component identified?
Is the COSO component identified accurate?
J) Has the preparer assessed the design effectiveness?
K) Do you agree with the assessment of design effectiveness?
L) Has the preparer documented any deficiencies (Control gaps) in the design effectiveness?

Process Flow Map