The narrative is the document which explains everything about your process. Management uses narratives to understand how the company functions, and staff use the narrative to understand what they need to do. Auditors use the narrative to confirm that the company's control environment works and as a benchmark for their testing.
Good process documentation is important because it demonstrates a company's ability to mange itself and integrates risk and control matrices and checklists. Here are five things every narrative must have.
Scope
Process narratives can't cover everything. That would make them unmanageably long, confusing, and difficult to read. Scope ensures that your narrative focuses on what's important. Scope also ensures that there's limited repetition and consistency between narratives preventing confusion by those reading them. There are a number of ways to set a focused scope:
Steps in processes which repeat across multiple processes can have their own narratives. A common example is the bank reconciliation. Regardless of whether money is paid via check, cash, or bank transfer, all processes will end with the reconciliation income to the bank account.
Processes which are similar, but have significant differences, should be separate. An example of this is payment methods. All invoices should be processed in the ERP system the same way; however, payment methods may vary. While they will all be sourced from the same place, what happens next is most likely different between cash and checks.
Subprocesses and references to other processes should be separate. Have you ever attempted to raise a purchase order only to find out that there's no approved vendor? Of course, you'll have to raise one, and simply referencing the vendor creation process should suffice. There's no need to replicate what you've already written.
The process shouldn't include a checklist. While we won't assume anything, the narrative doesn't need to say everything which a user or system might do before moving to the next step. Too much detail will reduce the usability of the documentation. Oftentimes it's possible to reference the checklist with a code or name, and that will suffice.
If there are different processes for different legal entities, they (may) need different narratives. As companies expand, they may need have more focused process for each of their entities. While an agile company will look to reduce these, in some cases there are regulatory and filing requirements which simply might be different or not applicable in some jurisdictions.
Automated vs. Manual
Every process will have automated steps and manual ones. The process narrative needs to state whether an action is performed automatically or manually. Consider the following:
The OCR system scans the invoice, and the details are uploaded into SAP Business One.
For someone who knows the process inside and out, this step looks straightforward and probably could be assumed. The problem is, that the narrative is supposed to explain everything about the process. This step is possibly missing a "how" and a "who". Depending on the process, this sentence could read:
The OCR system automatically scans the invoice and automatically uploads the details into SAP Business One.
or
The OCR system automatically scans the invoice, and the AP Assistant manually uploads the details into SAP Business Once.
The difference between the two is how much of the associated risks are mitigated and what controls might be needed. In the first example, the step in the process is fully automatic. The only controls needed most likely are monitoring controls. However, in the second example, there is a manual component to the upload of the invoice. Could the AP Assistant make changes to the invoice? How are those changes approved? Management would want to know how the business is kept safe, and auditors will ask how the associated authorization and compliance risks are mitigated.
Who or what (or Both)?
A good narrative explains who or what is performing an action, checking status, and pushing the process forward. Narratives need to describe in detail the responsible party for a specific task. Here's an example:
The AP Assistant sends the invoice for approval. An approver approves the invoice after confirming services have been received and the amount to pay is correct.
This task has given a general flavor of who is performing specific tasks. It's difficult to understand who is responsible. A more informative reading would say:
The AP Assistant reviews the invoice and determines who is responsible for the expenditure. They email the invoice to the approver, and the approver reviews the invoice. If the approver confirms that the invoice is for goods received and for the correct price, they approve the invoice via email writing in the body "this invoice is approved for USD XX,XXX". If they approver cannot approve, they return the invoice to the AP Assistant stating that the invoice is not approved.
The difference between the first example and the second example, is that the narrative now sets out who is responsible for the activity and what they actually do. Most components of the narrative will have decision making processes when members of staff are involved, and the narrative needs to say this clearly. Otherwise, the narrative will not provide a full understanding and application of controls may not be complete.
Can we move on?
In every step of the process, there's a need to move on to the next step. When writing a narrative, it's important to explain what steps a system or process does to confirm it can move on to the next step.
Just like the process itself, each step of the process has a start and an end. The narrative needs to explain each step. What happens to initiate it and what happens to end it in order to move on to the next step. Take the following example:
The AP Manager manually enters the invoice details into SAP Business One.
While this does describe what's happening, it doesn't really explain what prompts the AP Manager to perform this task. We hope they aren't inputting invoices they've created themselves! A more descriptive version of this would be:
The AP Manager checks the suppliers email box and manually opens the invoice. They review the invoice and enter the details into the invoice screen in SAP Business One. Once all details are completed, the AP Manager clicks submit.
This is more descriptive and explains what the AP Manager does, but is this step really complete? Can we move on? Here's a version which has a clear beginning and and end along with the process step:
The AP Manager checks the suppliers email box and manually opens the invoice. They review the invoice and enter the details into the invoice screen in SAP Business One. Once all details are completed, the AP Manager clicks submit. SAP Business One confirms that all required fields have been completed. If any have not been, SAP Business One displays an error and highlights the fields which have not been completed. Invoices entered completely according to the pre-set rules are accepted.
Now, the user of the narrative understand what causes the AP Manager to enter an invoice and how that step ends with the system confirming that all invoices have been entered completely.
Embed controls
What's a narrative if the the control activities aren't listed? The narrative is meant to explain the process and embedded in the process. Without a clear understanding of the control, how will someone reading the process understand how they affect the process? Here's an example:
The approver logs into SAP Business One and approves the purchase order after confirming that the vendor is correct, the price agrees to the contract or quote, and there is sufficient budget. SAP Business One prevents unauthorized users from approving purchase orders.
While it is true that SAP Business Once will prevent unauthorized users from approving purchase orders, the narrative does not detail how that's done, and SAP Business One is a central component of the process. SAP Business One actually is preforms the control. While the narrative does not need to explain the full process, the control itself needs to be explained, otherwise there isn't enough information to test that it works. The narrative should read:
The approver logs into SAP Business One and opens the purchase order. SAP Business One applies the user's approval access rights, and if the user has an authorization role applied, SAP Business One displays an approval tab on the purchase order. SAP Business One prevents authorized users from approving purchase orders. The approver approves the purchase order after confirming that the vendor is correct, the price agrees to the contract or quote, and there is sufficient budget.
The narrative now clearly explains how the control works and how the control itself is implemented. Someone reading the narrative is now able to understand what the control does and can audit it.
Clear narratives, lower risk, better control
A clear narrative proves to management and the auditors that the company has implemented strong processes and controls to mitigate operational and financial risks and will reduce the time spent in an audit ensuring that resources are not wasted on activities not central to the role. A clear narrative keeps your auditors happy because they have a process to test, and this reduces the overall audit risk.
Are you struggling with you narratives, and are your auditors taking up a lot of your team's valuable time? Advancing to IPO Ltd. understand how to write a clear and informative narrative for your auditors and your management team leading to lower audit risks and less effort passing your audit. Contact us today for a free consultation.