Exploring digital: empowering the Internal Control Function

Introduction

The Internal Control Function (ICF) uses a wide set of controls to make sure business and compliance risks are prevented or dealt with in the benefit of the company’s well-being. Many of these controls are manual. Using largely manual controls means a great deal of effort, time and money. Not only are these controls more time consuming and costly, they also cannot absorb the increasing complexity of today’s business environments in time, leaving the company possibly exposed to risks.

Let’s see what happening in the ICF market domain. The recently published Governance risk & Compliance (GRC) survey by KPMG ([KPMG19]) was initiated to get a better insight into the maturity of GRC, the level of internal controls and the adoption of HANA with organizations running SAP within the EMA region. More than 40 large organizations running SAP have been asked to participate in this survey. Relevant conclusions for ICF:

• Approximately 20% of these companies don’t have a centralized internal control repository
• Approximately 50% of these companies have less than 10% of their controls automated
• Approximately 70% of these companies identify control automation as a top priority
• Approximately 50% of these companies want to reduce their control deficiencies

Following this survey, it seems that while the top priorities of companies include further automation and reducing control deficiencies, the actual number of companies relying heavily on automation, using digital solutions, is low. While the relevance of digitizing seems evident, it is difficult to start, having a large landscape of applications and different control options available to you as organization. A logical question to ask is: how can we start to digitize our ICF?

This article shares client stories of ICF that used digital options, simply tools, to improve the way they operate across a variety of industries. We will outline how digital options can be used to lower the cost of control and improve the level of assurance of four different control types and what pitfalls should be avoided. We will also share relevant lessons learned and next steps based on our own experiences.

Digitalization options for the Internal Control Function

Digitalization of the ICF can be achieved in different forms. Some organizations start by implementing a tool or system to centrally manage and govern their risk and control framework. Some choose to go for an end-to-end transformation, where various tools and systems are integrating with each other, controls are automated and manual activities are supported by robotic process automation and low-code platforms. In the end, all companies try to achieve the same goal: increase their level of assurance while decreasing their cost of control. To help reach this goal we analyze a number of digitalization options using the CARP model. This model helps to categorize the different control types that will effectively reduce risks within a process or process step. CARP stands for Configuration, Authorization, Reporting and Procedural (Manual), which represent different types of controls (see Figure 1).

Figure 1. CARP model. [Click on the image for a larger image]

In Figure 1, the left side (C+A) of the model represents more technical controls, which can often be implemented directly in the ERP system, whereas the right side (R+P) of the model represents organizational controls which are embedded in daily business activities. Furthermore, configuration and authorization controls are preventive in nature while reporting and procedural controls are detective in nature. For each of the control types indicated in the model, there are digitalization opportunities. In the next section, some examples and use cases are provided for each category to provide a peek into the different options.

Configuration controls

Configuration controls are related to the system settings of an ERP system that can help prevent undesirable actions or force desirable actions in the system. These kinds of configurations can exist for the business processes handled in the ERP system as well as for the IT processes related to the ERP system. Therefore, a distinction can be made between “business configuration controls” also known as application controls and “system configuration controls”.

Examples business configuration controls

• Mandatory fields, such as a bank account number; when creating a new vendor in the system, these settings make sure no critical information is missing.
• Three-way match; this enforces that the purchase order, goods receipt and invoice document postings are matched (within the tolerance limits) with regard to quantity and amount.

Examples system configuration controls

• Password settings such as SAP parameters: “login/min_password_lng” or “login_min_password_letters” determine system behavior, such as the length of a password or the minimum number of letters used.
• More general system settings such as the number of rows that can be exported in a Microsoft Dynamics D365 environment determine a part of the system stability and are governed to make sure system performance is not impacted by frequent large exports.

In short, configuration controls are automated and preventive in nature which help organizations stay in control while not taking up any FTEs to execute the controls. Therefore, this type of control can be used to reduce the cost of control and increase assurance levels. However, there is a catch: how can the organization prove its automated configuration controls are set up correctly? And how does it prove that has been the case over time? To show how digital solutions can help solve this question, we present a use case of a large multinational where SAP Process Control was implemented to monitor the system configuration controls of 20 SAP systems.

System authorization controls

Are preventative measures taken to control the content of technical “roles” and access for users to those roles with the intent of making sure the right people can execute the right actions? In their efforts to manage access, companies generally make use of the below authorization controls:

• Segregation of duty controls. The ability to change vendor bank accounts is limited to a technical system role related to master data management. That role is only assigned to personnel in the master data management department, to people who are not directly processing transactions. Another role is limited to be able to do purchase orders. This limits the risk that one person can change a vendor bank account into a private account, and create a purchase order against it, for a fraudulent pay-out. The outcome is that certain activities or “duties” are segregated. Issues like this example are called Segregation of Duties (SoD) conflicts.
  
  [Vree06] zooms in on the relevance of Segregating of Duties and its impact, along with multiple improvement suggestions and [Zon13] dives into solutions for managing acces controls.
• Sensitive Access controls. Updating credit management settings often falls under the Sensitive Access controls. These controls are essentially lists of actions that can have major impact on the business, and access to it should therefore be limited and closely monitored. Unlike SoDs, this is a single specific action. In the example of credit management, access to the transaction code and object in SAP and the Permission in Microsoft D365 are normally monitored periodically, where any users or roles having this access are screened and adjusted where needed.

In short, authorization controls are very similar to configuration controls because they are part of the system and once created and assigned, they automatically do their job. These controls are strong preventive controls if set up correctly. Like in the case of configuration controls, there’s a catch: how can the organization prove that the authorization controls are set up correctly, and how do you prove that has been the case over time? To show how digital solutions can help solve this question, we present a use case where a company used Access Control tooling to assist in managing their access controls and making sure their roles are SoD Free or SoD-mitigated in a way that increases assurance and lowers the cost of control.

Reporting controls

Reporting controls are pieces of information combined into a format where a user can get to conclusions about for example the effectiveness of a process or the state of a financial. They are used to detect anomalies so that action can be initiated. Examples are:

• Related to the SoD example mentioned under authorization controls, a manager in the internal control department wants to know how many SoD conflicts were reported last month, the actions that were taken to fix them, the status of those actions and the real risk the business is now facing. A dashboard, for example in BI tooling such as MS PowerBI, Tableau or Qlicksense or as part of a risk platform such as the earlier mentioned Sofy, SAP Process Control, can be a great tool to visualize and report on the status of the authorization controls. Especially on this topic, many lessons can be learned, and we highly recommend reading the 10 most valuable tips for analyzing actual SoD violations ([Günt19]).
• A manager in finance running a report that checks the systems for duplicate invoices, so that double payments to vendors can be prevented or payment of duplicated invoices can be retrieved from vendors that were paid twice.

In short, reporting controls are generally detective in nature as they present information about something that already has occurred. While the Configuration and Authorization controls try to prevent risks, there is always a residual risk and this is where reporting controls come in, to detect any mistakes or fraudulent behavior that got past the preventative controls.

These reporting controls can be very strong when the executers of those controls are supported by strong dashboards and analytics. In the Compact special of January 2019, [Zuij19] presented a case on advanced duplicate invoice analysis. The article explains how they implemented smart digital tooling to create a duplicate invoice analysis at a major oil company. We advise reading this in-depth case, because it could provide helpful guidance on how reporting controls can be digitized to unlock the power to identify conclusions that were invisible or inaccessible before. This can directly increase the assurance level of this type of control because insight is provided that wasn’t there before, and at the same time, it decreases the cost of control, opening up the possibility to gain back any invoices that are paid twice. Additional examples are:

• Automating the running and sending of reports using SAP Process Control
• Creating an analysis to identify the use of discounts in the sales process using SAP HANA or SQL
• Unlocking faster decision-making by providing the organization with real-time overviews of the state of internal controls. This can be achieved with a live Dashboard using Microsoft PowerBi in combination with Outsystems and SAP Process Control, or KPMG SOFY

Procedural (manual) controls

Procedural controls are manual actions performed by a human, initiated to prevent or detect anomalies in processes. They help companies cover residual risks that are not easily covered by Configuration, Authorization or Reporting controls. Examples of manual controls are:

• Signing off documents such as contracts, large orders, etc.;
• Manual reconciliation of received payments against invoices, with or without the use of a system;
• Manual data alignment between the sales system and invoice system.

Controls executed by humans, such as Reporting and Procedural controls compared to ones that are executed by a machine, have the inherent risk of the human operator making mistakes, because making mistakes is human, especially when the complexity and receptiveness of a control increases. As business complexity and the volume of data is increasing, companies are now looking into solutions that can replace or enhance human-operated controls with automated digitized ones.

To show how manual controls can be improved using digital solutions, we present a use case focused on reducing manual actions or at least reducing the effort and increasing the quality of their output. In this case, Robotics Process Automation (RPA) tooling was used to automate manual journal entries, resulting in fewer manual control actions. This reduces the cost of control because fewer FTEs are required to operate the control. Secondly, the level of assurance increases as a robot will not make mistakes even when the repetitive task is executed hundreds of thousands of times.

Lessons learned: digitizing the right way

Like other projects, digitalization projects can be challenging and will have pitfalls. In this section, we will provide examples of the pitfalls we encountered, and explore how they can be prevented.

Determine the baseline

In several cases the goal of a project is set without first analyzing the starting point of the project. This can result in unachievable goals, which will cause the project to be a failure. For example, if the goal of a digitization project is: “we would like to fully automate the testing for 50% of the controls in our central control framework using tool XYZ” there are several prerequisites to achieve that goal:

1. Tool XYZ should be capable of automating the testing for these controls.
2. The feasibility of automating the testing of controls in the central control framework should be determined beforehand.
3. The end users should be part of the digitization journey to make sure they understand the tool and understand how it can be embedded in their process

In this example, setting the baseline would consist of analyzing the controls for feasibility of automation in general, then checking whether tool XYZ is capable to facilitate the aimed automation and then engaging the business users before the project starts.

Once the baseline is determined, an achievable goal can be set, and the project will have a higher chance of success.

A fool with a tool is still a fool

The market is full of tools and technology solutions, some with a very broad range of services, some with a specific focus. Each of these tools have strong points and weaknesses. These tools are often sold using accompanying success stories. However, even if the best tool is used in the wrong way, it won’t be successful.

As an example, we could consider SAP Access Control, a tool which can be used to monitor potential Segregation of Duties conflicts in an ERP system. When the tool reports SoD conflicts, an end user should follow up on the conflicts. In the case of SAP Access Control, a user has the ability to assign a control to an access risk to let the system know the risk has been mitigated. In reality, many users assign a control in the system to hide the results of SAP Access control by showing them as “mitigated”, while in reality the actual risk in the ERP system is still there as the control is not really executed. In this case, the tool is just as good because the end user decides to use it. Good examples of how to use this tool properly can be found in the article of van der Zon, Spruit and Schutte ([Zon13]).

To ensure that a tool or solution is used in the right way, make sure that the end users are involved and properly trained in the tool or solution. If they see the benefits, the adoption will be easier and the tool or solution can be used to the full extend, moving towards a more digitized organization.

Who controls the robot?

Governance is an important topic in relation to technology solutions. In a landscape where controls are tested automatically, reports are being generated by a data analytics platform and manual tasks are performed by robots there is still manual intervention of humans.

The automated testing of controls needs to be configured in the tool or solution. As part of the implementation project this is probably tested and reviewed, but what happens after that? How do organizations make sure that nobody changes the rule-based setup for the automated testing of the controls? This question is relevant for every tool or technology solution used for digitization of processes. If there are separated robots to perform conflicting activities within a process, but both robots can be accessed by the same person, the conflict and underlying risks still exist. To resolve this, proper governance of the technology solution or tool should be put into place.

Working together

In larger corporations, each department might have their own budget and their own wishes and requirements. However, if each department is working on digitizing individually, a lot of effort is wasted. Re-inventing the wheel is costly and will slow down overall progress.

When all powers are combined, requirements are bundled and effort is centralized, digitizing the processes will make more sense and implementation can be faster and cheaper. It’s about connecting individual digitizing efforts to achieve the next level.

Conclusion

The digitalization of internal control entails more than selecting and implementing a new tool and learning how to use it; it is the use of digital technologies to change the way the business or a department works and provides new value-producing opportunities for the company. Onboarding new tooling will therefore require enhancements on your operating model to be set for success.

Different aspects of the operating model need to be considered. Think of the potential impact on the ICF when automation impacts the role between the business and internal control. People and skills are impacted when internal control takes a role in the configuration or maintenance of automation rules, requiring certain technical capabilities and skillsets. In today’s digitalization, a more agile way of working is usually better, potentially impacting the required capabilities of the internal controllers. From technology perspective, automation has a major impact because of the integration within or connection with the existing IT landscape. This is even more so the case when RPA is used, impacting aspects such as governance, maintainability and security. Finally, automation within the internal control realm will have an impact on the current way of reporting, also considering auditability.

Taking the time and effort to define the impact on the operating model of your ICF and to devise a detailed plan on how to use digital control options, is the key to success.