Listen in as PwC Senior Consultant and GRC 2014 speaker Brian Perrotto describes how to mitigate specific financial risks using automation and workflows within SAP Process Control. Brian has experience implementing SAP GRC solutions for large global clients and has been involved in a number of GRC Process Control implementations with a focus on design and configuration of rules for continuous controls monitoring, master data (MDUG tool), delivering training and knowledge transfer documentation, as well as performing system validation tests.
Transcript of podcast:
Dave Hannon: Hello and welcome. This is Dave Hannon with SAPinsider. Joining me now is Brian Perrotto, a senior consultant at PwC. Brian’s going to be speaking at the upcoming GRC 2014 event in Orlando, and he’ll be giving advice on how to mitigate financial risks and automate the testing of financial controls using SAP Process Control. Welcome Brian, thank you for joining us.
Brian Perrotto: Thanks for having me.
Dave: Brian, your presentation focuses on the automation capabilities of Process Control, and one of the risks you’ve outlined is general ledger accounts that are configured as automatic posting only, meaning they don’t allow for manual general posting. What’s the risk SAP users should know about there, and how can it be minimized?
Brian: Sure, so within SAP there’s obviously many different settings for each GL account, and one of the most key ones when you’re talking about financial risk and especially manual journal postings is the indicator on the GL account that identifies whether you can post automatically only to the account, and so what that means is that if you turn that setting on, the only postings that can go to the account are those that come from the SAP system account determination tables, a user can’t try to post an entry directly to that account. So the risk that that addresses is that if you have accounts that are not designated correctly as post automatic-only in your GL master data, you have the potential that those accounts could allow for adjustments or have manual journals posted to them, when really none of those postings should happen. So obviously by limiting the number of GL accounts that you can post to manually, you’d reduce your overall risk in that area.
Dave: Ok great, great. You also covered the risk of manual generals that are traced from the system to the supporting documentation. Can you describe the risk involved there and how it can be addressed by SAP users?
Brian: Absolutely. So manual journal entries are a common item that comes up at our clients, and that’s, part of that’s a function of SAP and the FI-GL, it can be hard to identify your total population of manual journal entries, so almost all of our clients will have controls referencing manual journals and being able to trace those manual journal entries to source documentation. The challenge that comes in is that, in SAP itself, it’s not just a quick indicator or flag on the accounting document that says “this was posted manually,” instead you have a series of filters or criteria you need to look for in the document posting tables within SAP. So just to give you some examples, in our previous question we talked about accounts that you can post to only automatically, obviously you would want to weed any postings made to those accounts out of your population. And then there’s a series of other configurations, such as document type configurations, so some document types may only allow batch postings, for instance, so you would filter those out and then lastly, outside of configuration, you may also have some user IDs that cannot be logged into, they may be used for batch jobs or interfaces. So again, you’d want to take those postings out so that in the end, you want to build a nice, tight picture of these are the journal entries that are left, and we know they were posted to manually. Unfortunately, there’s no “yes or no” for was it posted manually, so it’s kind of a series of configurations and other factors that you need to take into account to get down to that population, and Process Control can help with each of those areas and then lead towards putting in a monitoring mechanism using the tool.
Dave: Ok, good. I wanted to ask a little bit more about the monitoring of manual journal entries and Process Control. What are some of the things users should know about this capability?
Brian: Right, so as I discussed previously a lot of configuration goes into getting to your population, so one of the biggest things that clients run into is that the population of journal entries in SAP could be quite large, as I mentioned, all the automated and manual journals end up posting to the same tables, BKPF and BSEG, and those tables are quite large and in Process Control you do need to be careful about the amount of data you’re pulling down, so what you need to do is try to be as specific as you can with the filter criteria and the business rules, and you want those filter criteria to include the items we mentioned in the previous question, so you want to make sure you only bring in the document types that allow manual posting, you want to make sure you only are including GL accounts that permit manual postings, and then bringing in the other factors such as the transaction code used to post the journal, the user ID that posted the journal, so that you have a business rule that’s very specific and gets you down to the actual data that needs to be reviewed, so that the volume of the transactions is more manageable, so what you end up with is a very targeted business rule to identify the manual journals, on top of that for each of the filter criteria that I just mentioned, you should also have another business rule that could monitor each one of those configurations to let you know as a Process Control user if you need to go update the overall journal entry business rule. So what I mean by that is you could build a business rule to identify document types that allow manual postings, and if a new document type got added to your SAP system that allowed manual posting, Process Control would kick off a workflow and alert somebody to that fact and then that person could make the judgment of whether or not the overall monitoring rule for the manual journal entry needs to be updated. So you would follow that same process for each of the filters that you put into your automated business rule that’s used to monitor manual journals, so what you’d end up with is one overall rule that presents the journal entries that are to be reviewed, but you would also monitor each of the key configurations that drive the filter criteria for your business rule.
Dave: Ok. You mentioned workflows and that was an area I wanted to ask you about. Do you think there’s an aspect of workflows that Process Control users tend to miss, maybe a step in the configuration or a benefit that they don’t realize that they could be getting from this?
Brian: It’s not so much I guess a step in the configuration or a technical issue that we see users encounter; it’s really more about the people that the organizations identify as the individuals who should receive workflows. So what I mean by that is, workflow obviously is an excellent way to drive accountability within a compliance organization, and in order to get the most out of your workflow, you need to be able to identify the individual who is truly responsible and/or owns the control, and beyond that is empowered to respond quickly to any issues that come out of Process Control. What you want to avoid is having a business rule that runs and identifies exceptions, gets delivered to an individual, who then cannot actually take action on that result, so you want to avoid delegating responsibility for resolving those issues within the tool itself, you want it to go to the actual person who can influence the required change in order to be compliant with that control activity.
Dave: Ok, great. Lastly, when it comes to automation overall, is there an overarching message that you give to Process Control users?
Brian: Sure, I think there’s plenty out there but the one that I see most often is—don’t fall into, the trap that Process Control can automate all of your key testing tasks. What’s often really important is to understand that sometimes you have results in Process Control and you can automate a lot of the steps and get you almost there, but you still need someone who’s knowledgeable at the control and the output to review that and interpret it and understand what it means for your organization. And in addition, before you can even begin to even understand what you should put into Process Control to be automated, it’s important that there’s a thorough understanding of the core SAP system, and the configurations and automated controls that address all the key risks that your business—you want to kind of lay that out and use that as a way to plan what you will automate in Process Control, you don’t want to try to automate things for the sake of automating them, you want to really take a risk-based approach, understand what key SAP configurations mean for your SAP environment and how they support your key controls, and start there rather than trying just to automate everything you can possibly automate. You want to try to target that to automate the items that you’re going to get the most benefit from.
Dave: Ok, Brian Perrotto, a senior consultant at PwC. Thank you very much for joining us today, it was a very interesting conversation.
Brian: Thank you.