So if you remember, a control is put in place to mitigate a risk. Here are some key risks that we are trying to control with an approval control:

• The risk that an inexperienced subordinate accidentally processes something incorrectly
• The risk that an experienced subordinate purposely processes something incorrectly
• The risk that unusual or questionable activity makes its way through the system
• The risk that a company policy is violated by improper employee processing
• The risk that company policy is violated by system generated processing
• The risk of an employee committing fraud

If you read last week’s blog, you’ll notice that a lot of these are similar to the risks that are controlled by reconciliation. This highlights an important point. There can be multiple ways to control a risk. However in practice, it’s best to limit the amount of controls in your system, as this is the point where a lot of recurring cost for your company comes ( e.g. controls need to be tested on a regular basis ).  That said, it’s good to know that you have some options, because all controls need to be effective. If you have an ineffective reconciliation control, then perhaps an approval control might be appropriate to bridge the gap.

Here are some key tips for designing approvals into your compliance data system.

Tip # 1 – Downstream the Correct Data From Your HR Database

Downstreaminging from your HR database always makes people nervous, due to privacy issues. The information that you need should not violate any privacy policies, but you will probably have some explaining to do.

Here’s the data that you need from your HR Database. I’m going to use Oracle ERPish column names in case they are familiar to you, however you should be able to translate if you’re not using Oracle ERP:

• USER_ID – You need some way to link in your employee to your transactional data. For obvious reasons, you need to bring this in.
• EMPLOYEE_ID –This is only optional in very small companies or in companies where the EMPLOYEE_ID and USER_ID are the same. Employee ID is important to distinguish different people that have the same name.
• EMPLOYEE_NAME – Duh. Make sure you bring in the full name of the employee. You do not want to be in the middle of an audit, trying to decipher what “JAMESF” means.
• PHONE – The employee’s phone extension. Very handy when you need on the spot answers.
• EMAIL – The employee’s email address. Once again, if the employee doesn’t answer the phone, it’s nice to be able to shoot off a quick email. These kinds of things demonstrate to the auditor that you are running an efficient compliance operation.

I suggest you denormalize this information out to every data point that references an employee. Or if you are building a star schema, have at least two dimensions that contain this data; one for worker bee, and one for approving manager.

Tip # 2 – Store Images of Physical Approvals

If there are hard-copy manager approvals available in digital format, downstream from this system and attach them along with the approval. In my blog entry “Prove It or Lose It!” I demonstrated the need for evidence in a compliance data system. Here’s a perfect example of where that comes in handy.

Pulling this off can be tricky, if your infrastructure has a hard time with BLOBs ( Binary Large OBjects ). Obviously, a database like Oracle can handle the storage, but what about your retrieval system? If you find this to be a challenge, one trick is to just store a reference ( i.e. website URL ) to the approval. Although this is not ideal, it’s 1000 times better than having no physical record to access. If your physical documents aren’t currently web accessible, suggest building it. It shouldn’t be that hard if you keep the scope under control (look out when they start saying, “Great idea! We can actually build a general purpose system for approval retrieval that will work for the whole company!” This will be a nightmare and your basic function will be put on hold until it’s done).

Tip # 3 – In The Absence Of An Approval System, Create One

The best approval control is executed before the transaction(s) occurs. This can only be done in the transactional system, and I’m not suggesting you try to interject there. The second best thing is to have the approval done after the transaction(s) has occurred. Although this is not ideal, it’s better than not having any control at all, and this is something you might have control over building.

In last week’s blog, I suggested that you consider an auxiliary system to support data you cannot downstream. This is the appropriate place for an approval control that is after the fact. As an example, you could have a report ready for a manager that details a number of related transactions. The manager would review the report, then submit an approval through your system. This doesn’t need to be complicated, just some acknowledgement that somebody looked it over and approved it. This approval data point would then be captured, and attached to the rest of the data. Like I said, not ideal, but much better than not having the control at all.

Tip # 4 – Design With The Auditor In Mind

This should be the common theme for the design of your entire compliance data system. Imagine your user sitting in front of an auditor, trying to answer questions. What is the quickest way I can get my user the information?

To demonstrate control, you will want a comprehensive report that lists all approvals, and what they’re for. From a tactical perspective, a specific approval control needs to be immediately accessible when a transaction is under investigation. With the response should come all the data on the approving manager ( name, phone, email, etc. ), when the approval was done, and physical evidence of the approval. This is powerful! Two or three times down this road, and the auditor is going to leave your users alone.

Approval controls are another way to control common key risks in the company, so plan on building systems that incorporate them. Making sure you have good approval disclosure built into your system is vital. Keep in mind the important data points that you need on approving managers, and always design with the audit in mind. With infrastructure like this, your compliance data system will be bulletproof!