STOP! The Controls Madness . . . Part deux!

In Part 1 of this post I talked about the fact that the relationship between better risk management and more control is not intuitive or even direct. We discussed the shortcomings of the traffic light system as a control. We also touched on the issues in financial control with the false sense of security created by automated controls, such as those for purchase limits for example. You can read Part I here . . .

The same challenge exists for the classic accounting control,
 the 3-way match of PO, Goods Receipt and Invoice processing. The control being you can't process an invoice without a goods receipt or a goods receipt without a valid PO. We set such a policy for indirect procurement, we embed that in the configuration of our ERP/Financial system and away we go. Even when I test these embedded controls, everything looks good as I can prove these configurations are set (both centrally and not over-ridden for certain suppliers, hopefully! Although that is another story!).

Again, this can obscure the real risk. Even a perfect 3-way match setup (which is surprisingly rare even in these times of strong control focus) can be undermined in a number of ways. I have written many times before that any system only can control the sequence of data entry not the actual business process (this is one of the inherent risks in the received wisdom that a contemporary ERP will automate a business' controls). If you are not familiar with this thinking, I illustrate it here . . . but it has been suggested I should have a post explicitly focussed on what these tyre tracks mean in risk, control and system terms . . .

So, for 3-way match for example, we need to monitor data as well as the controls to check for POs created at the same time (or just before) GRs or IRs. This is because, although a well configured system will ensure we can't process a GR without a corresponding PO, the system won't stop a PO created just prior to a GR entry, which probably reflects a circumvention of the proper purchasing process.

Another example is one of auto payment tolerances. With a 3-way match embedded in the system, it is reasonable to suggest such 3-way match invoices can be auto-approved for payment, saving effort, time and money. However, if the payment tolerances are set to 30%, for example, this can substantially undermine the control and expose the key risk again.

The the key challenge is to continue to educate and reinforce that the issue is RISK and not just CONTROL. Control is the 'HOW' to the 'WHAT' of risk.

The problem is not in the concept of controls, or even their implementation. The issue is the lack of appreciation of the 360 degree view of risk, where preventive controls can only be a part, not the complete solution.

Consequently, for key risks, we need to monitor preventive controls such as Segregation of Duties, Restricted Access, System Configuration and embedded Process Controls. BUT THIS IS JUST A COMPONENT, not the complete control system. We also need to monitor data and transactions so we can assess the underlying risk itself and to ensure the controls are achieving their expected objective.

Monitoring controls is useful, but not a comprehensive risk management approach for financial assurance.

We must always challenge and prepare to be challenged on potential over-confidence in our control environments. I suggest you use case studies, workshops and external facilitators to drive out the various scenarios that risk may become reality. Even a one-time analysis of key data for a core process can highlight the issues to stakeholders quite dramatically.

Now to be clear, with respect to traffic lights in part I and to configured controls here, I am not advocating eliminating controls or eliminating the traffic light. I AM advocating a more judicious and thoughtful use of preventive controls combined with a broader set of risk management and monitoring tools.

Yes, monitor controls. But critically, monitor transactions and data too.

Experience informs us that this will save a lot of unnecessary pain later . . .

Thanks for reading