Controls Terminology And Traditional Controls - Part 1

Following Marc Jackson’s  insightful webinar on Controls Automation in the next 3 blogs we will , the terminology, the new breed of Controls walk you through using Controls Automation

Increasingly the market is focused on automating controls to reduce the cost of compliance, improve the control environment, and realise efficiencies. More than ever now, organisations are completely information-driven and data has become the lifeblood of any business. In the past, organisations were able to manually verify and audit the accuracy, consistency and reliability of the information they used due to low-volumes and relatively stable mainframe-based information processing environments. However, with the advent of distributed technology, data volumes and compliance requirements have increased exponentially. As a result, the use of manual controls has become costly, obsolete and simply not sustainable.

Despite organisations becoming more and more aware of the value and benefits associated with controls automation, the current situation is not what you might expect. With the exception of a few progressive organisations, controls in most organisations are compliance-driven and often implemented following a risk event. It is not uncommon for manual controls accounting for more than 70% of key controls within an organisation, and there have been many studies and surveys which all provide similar conclusions

So why is this the case?:

• Controls tend to be implemented as a knee-jerk reaction to problems
• The absence of any recent and/or glaring information-error event means control automation projects take a backseat and compete among many organisational priorities
• For some executives, especially those who are not accountants, risk and control-related terms can be confusing and misunderstood especially when the focus is on heavy theory
• Implementing further technology to automate controls can also be a seemingly expensive proposition.

We’ll take a closer look at some further challenges faced a little bit later on, but right now let’s refresh our understanding of some of those commonly used control terminologies

Controls Terminology

As I’m sure you’re all aware, controls are typically categorised in terms of their nature and type, each of which has two buckets for classification purposes. The nature of a control is determined based on whether it is preventive or detective:

1. Detective controls: will identify when a potentially undesirable activity has taken place, they will not stop it from happening but they will allow an organisation to respond appropriately and in a timely manner – so they’re very much reactive or “after the event” (e.g. a monthly review of payroll audit reports help identify potentially incorrect or unauthorised payments that have been made, such as duplicate payments or unusually large amounts, so they can be corrected as required).
2. Preventive controls: on the other hand, will prevent an undesirable activity taking place, which avoids the need for potentially complex and lengthy investigations and associated corrective actions so they’re very much proactive or “before the event” (e.g. 3-way match is a well-known configurable control ensuring quantity and price matches between PO, GR & IR according to customer-defined tolerances, otherwise the associated invoices are blocked for payment).

The control type is determined based on whether it is manual or automated. The difference between these two types of controls is relatively simple, manual controls require human intervention for them to operate whereas automated controls don’t, they are performed entirely by the system/application (e.g. you can configure an automated check on customer credit limits during order intake, if the credit limit is exceeded then the order is prevented).

You may have also heard controls referred to as “semi-automated” or “IT dependent”, these are controls which rely mainly on human intervention for their operation but they are also reliant on data provided by supporting technology. Therefore, these would include any controls involving the manual review of system-generated reports, so the manual review of FF logs is a good example. It’s important that an organisation’s internal control framework has the right balance of manual, automated, preventive and detective controls. Although preventive controls are stronger as they stop undesirable events taking place, detective controls are also important to pick up on anything that slips between the gaps, which may also be symptomatic of automated control failures.

Traditional Controls

When people hear the term automated controls they usually think of those configurable controls which are available within your ERP system that can be switched on and defined to suit the way an organisation’s business processes operate. These controls are commonly referred to as “Application Controls” and are embedded within an organisation’s business processes providing input, processing and output controls. For organisation’s embarking on a journey of automation it is strongly recommended that these controls are reviewed initially as they are readily available to use in your system, you don’t need to purchase additional hardware or software, only the relevant level of knowledge regarding the available configurable controls in those business processes being operated by your organisation.

These traditional automated controls are not only restricted to business process-related configurable controls, they also incorporate security-related system parameter settings which help define and automatically operate logical access and authentication controls. In addition, although perhaps not realised by everyone, restricted access controls are also another form of automated controls as taking away inappropriate access, whether it be for SOD or Critical Access risk purposes, removes that access risk from the user and will continue to do so without the need for any human intervention.

Example: A company can make use of a system configuration-based control which can prevent field changes to financial documents after posting to the General Ledger has taken place. For example, you’d want to prevent changes to vendor bank account details to reduce the risk of inappropriate payments. From a control perspective, if a document needs to be changed for valid reasons then it should be reversed and the correct document posted, providing full transparency into all transactions affecting the SAP General Ledger. Therefore, this helps to protect the accuracy & validity of financial reporting. An alternative manual control would involve extensive and time consuming reviews of GL document changes, so you can begin to see the positive impact of implementing automated controls.