Formalising the controls

All businesses perform controls to varying degrees.  The difference lies in the way that the controls are performed. Formalising the controls allows your risks to be managed proactively and methodically, instead of reactively and inconsistently. Your first step is to identify the risks which exist in your business.

How are you supposed to know what risks there are in the business? Perhaps your organisation has experts who know what to look for and how to do this. If you are an investment bank, you would have specialists who identify and manage risks in order to maximise your gains and minimise your losses in the stock market. If you operate a grocery store, some of the risks you would focus on are those in your supply chains.

There are a couple of factors you need to determine before starting your risk identification exercise:

• The process for which risks are to be identified
• The objective of risk identification

The risks that you identify may differ depending on the objective of risk identification. An auditor, for example, would mostly be concerned with risks which result in financial postings. An engineer might be more concerned with the possibility of equipment breaking down.

An example

We will take you through the process of identifying risks in the Purchase-to-Pay process from the point of view of a financial auditor.

The diagram below shows the typical basic subprocesses in an end-to-end Purchase-to-Pay (P2P) process. Every complete P2P process will have purchase order, goods receipt, invoice and payment subprocesses. Some may also have a contract, a purchase requisition or other additional steps.

First of all, we need to identify the subprocesses which result in financial postings.

As shown above, our concerns would primarily be on the subprocesses which directly or indirectly impact financial postings. These financial postings take place at these points:

• When goods receipt is posted
• When an invoice from the vendor is posted
• When payment is made to the vendor

Purchase ordering does not lead to financial postings. However, purchase order is an essential document in the P2P process, which is also legally-binding once accepted by the vendor. Additionally, in a typical system-based P2P process, data from the purchase order is automatically copied over to the subsequent goods receipt and invoice; therefore, purchase order is also a subprocess that should be considered in this exercise.

For all the relevant subprocesses, we do the following:

• Identify the main risk(s). For each risk, we ask what could go wrong. This will give us the basic scenario which could lead to a violation of the risk.
• Expand each scenario to establish situations specific to each subprocess that could lead to the risk being violated – we will call it ‘how it could go wrong’. These situations should be specific to how you perform each subprocess in your business.
• Determine a control to address each of the situation identified in step 2. Whether you choose to operate the control or not can be decided upon at a later stage.

Step 1

The table below shows step 1 for the P2P process. As you can see, the risks and ‘what could go wrong’ identified could apply to any business running a P2P process.

Step 2

Step 2 is shown below. We will take the purchase ordering subprocess as an example. This step should be performed for all the other subprocesses too.

Once we have broken down the scenario into various situations, you may see a situation which does not apply to your specific subprocess. For example, some businesses may not use a purchase order approval process; instead, they may have a purchase requisition approval process. If this is the case, then they may want to identify risks and controls in the purchase requisition subprocess as well.

Step 3

In step 3, we go further and identify one or more controls for each situation. As per the step before, the controls will have to be specific to the way you carry out your purchase ordering.

Step 3 shows some common controls which can be used to manage risks in the purchase order subprocess. We are using SAP as an example where this process is conducted. Some parts in the subprocess, however, requires user input (i.e. human intervention) and therefore there will also be controls which take place outside the system.

Final words

Please bear in mind that this article is supposed to demonstrate how you could walk through the process of identifying risks, designing the corresponding controls and checking the controls. What risks and controls are relevant to your business will depend on the purpose of risk management, the process you have, any system (IT or otherwise) that you have in place.

Good luck in your journey in establishing your risks and controls! If you need any help in building your framework of access risks and controls, have a look at our service here.