IPE and SOX Readiness Considerations: Building a Consistent Process

Over the past years, additional documentation and testing requirements have been brought up regarding IPE (Information Provided by Entity). With the renewed focus on IPE, internal audit leaders Mukesh Arora and Lin Wang share examples and learnings about system considerations for IPE, their experiences in IPE testing, and the practice of building a consistent IPE process, including:

• What is IPE — and how to identify different types of IPE.
• Completeness and accuracy risks in the IPE process and how control owners and auditors can address them. 
• Concrete steps to create a consistent process for IPE irrespective of application/technology.

Watch the full conversation for step-by-step examples, SOC report reliance considerations, IPE configuration testing, and more — and read the can’t-miss highlights below. 

What Is IPE?

“What is IPE? IPE is any information that’s used by the entity or created by the entity. You may have come across end-user computing, which is where you’re using an access database or other query tool to connect to a system and pull data out of it. In the current context, based on what we have seen, it is a lot broader. Even if information is produced directly from the system that’s used either in a control or as part of audit testing, we are treating all that as IPE.” – Mukesh Arora

“Audit teams and control owners encounter IPEs in different ways. Obviously the control owners use it as part of their processing or control execution, while auditors receive this information in making our collections or when we are testing controls. One example of an IPE is… a bank statement provided by management to us. From an audit perspective, that’s an item that we have requested and we use it as part of an audit procedure as the data set or data element that has been provided.” – Mukesh Arora

What Are the Different IPE Categories?

“We’ve tried to classify IPEs into different categories. One of the challenges that we have run into is that there’s not a clearly defined classification or authoritative guidance that identifies specific categories for IPE like there is for controls with preventive controls or detective controls. The categories we have here are a little bit detailed and exhaustive, but by no means is this the only way to classify IPE. 

1. System-generated could be either a canned report, a custom report, or an ad hoc query that you’re coming, that you’re generating it from. 
2. Third-party report could be the earlier example of bank statements. It’s provided by a third party that we do not have any control over. 
3. Manually-compiled could be manual time sheets from employees, which we put all together perhaps in a bigger ledger, and then create a spreadsheet out of it. 

These are the different categories that we have encountered based on our experience.” – Mukesh Arora

Completeness and Accuracy

“Completeness is making sure that there’s nothing that’s been omitted from the records, and accuracy is to ensure that the data and the transaction or the data is accurate, which is consistent with the originating transaction data. 

One of the things that I think is worth looking at is the U.S. Government Accountability Office definition of data reliability into three categories: either the data is sufficiently reliable, or it’s not sufficiently reliable, or data you cannot determine the reliability of it. It sounds very fairly intuitive, but I think when you actually start looking at every data set and you try to categorize it into these categories, it helps you when you’re auditing.”  – Mukesh Arora

What are the Risks in the IPE Process? 

 “I would like to explore what are the risks in the IPE process? What can possibly go wrong?” – Lin Wang

1. Source data processed by the application to generate IPEs. “If we think about the whole IPE cycle and the completeness and accuracy requirement from the very beginning, IPEs are generated using source data. At the end of the day, this source data is what’s actually making up the content of the IPEs. If something went wrong in the process of entering or processing the source data within the application, it will cause the IPEs to be not accurate and/or not complete.” – Lin Wang

2. Data extracted from the application (using parameters or defined ranges). “Moving on to the next stage of the cycle, in the process of the application generating the IPE, the user may need to manually enter certain parameters or define a range. For example, you generate a certain report for a date range, for the past week or month. These parameters that are manually input by the user can be inaccurate in the process of being entered due to manual errors, fat fingers, etc. Once the parameters get entered, the application will use those parameters to gather the data from the system to generate the IPE.” – Lin Wang 

3. Computations performed from the application (creation of the IPEs). “Let’s say the system was supposed to generate the past week’s data, but somehow the system incorrectly generated data for the past two weeks. Now the IPE contains inaccurate data that’s different from what you want, creating another risk that potentially causes inaccurate or incomplete IPE.” – Lin Wang

4. Transfer of the data output from the application to the end-reporting tool. “Once the IPE is generated, sometimes the data needs to be transferred from the source application to a different application. For example, a journal entry application moving on to a financial reporting application if those applications are separate. In the process of transferring all this data, something can happen in the middle. If it’s an editable report, maybe in the process of downloading and re-uploading something got changed or omitted. This will cause the final IPE used in the reporting tool or end application to be inaccurate or incomplete.” – Lin Wang 

5. Further manual updates added. “Certain editable IPEs can be manually modified after they are generated from the source system, and those manual manipulations can cause the generated IPE to be not accurate or complete.” – Lin Wang 

Completeness & Accuracy: Considerations for Control Owners

“What we have learned so far is that risks can arise from various stages of the IPE process. What can we do to address these risks? From a control owner or process owner perspective, what can we consider when we think through the method we’re going to implement or procedures we need to perform to address these risks? 

We want to make sure that the content included in the final IPEs is actually in fact the data and the content we wanted to be included. There are some very basic steps you can take when you verify that the final content is what you want. 

1. You can verify the name and type of the report. For example, if you are trying to generate a report containing the timesheet data, the hours data, but then the name of the report indicated it’s a new hire report, clearly you’re generating the wrong report and it will contain the wrong content. 
2. If the IPE needs parameters to be entered manually as part of the generation, you want to verify that the parameters you entered are accurate and consistent with what you intended to enter. 
3. Think through how we rely on the applications and systems to make sure that in the process of creating and generating IPE it is grabbing the accurate data and performing the correct calculation and classification so the final generated IPEs are accurate?
4. When we talk about certain manual manipulation of IPEs that can happen after the IPEs are generated, management may consider what format of IPE needs to be generated. In certain applications, when IPEs are generated, the system will offer you the option of Excel or PDF. Considering these options and what you’re going to be using the data for, using a PDF format might reduce the risk because it’s not editable.
5. In certain situations there is an option for the user to include the parameters used when generating the IPE as part of the IPE. Including that section in the generated IPE will help the end user to verify again once the report is generated the parameters are accurate. 

It is very important to point out that it is the control owner’s responsibility to demonstrate that the information used in the performance of a control is complete and accurate. This can be obtained via training or raising awareness with the control owners. Especially in a newly-established environment with control owners who may be new to the SOX process as part of SOX readiness, it is essential that either the internal audit department or other training department provided enough training for the control owners to be aware of the potential risks and procedures that can be performed to ensure data accuracy and completeness.” – Lin Wang 

Completeness & Accuracy: Considerations for Auditors

“Let’s talk about the completeness and accuracy assessment from an auditor perspective, especially in environments that have users with the ability to both define and extract. What are the sources of data contained in the IPEs?

Returning to the example of the bank statement, if I’m getting something directly from the bank I don’t necessarily have a whole lot of levers, versus a user that’s actually extracting data from a system using a unit query tool and then utilizing manual input to work on it. It is a completely different scenario, so you would have to first get a clear understanding of what the data source is. 

If you’re looking at a system-generated IPE, there are a couple of considerations. Whether it’s an on-prem application versus a cloud-based application. For SOC report reliance, if it’s a cloud-based application, can you actually obtain ITGC reliance on a system? Which is actually a really critical part. We have encountered systems where we could not get any ITGC reliance on a system at all, which made it very difficult for us to get comfortable with the data. If I’m not comfortable with the change management on the system, how do I know that every time the data is extracted, it is complete and accurate? 

Consider the format of the report, whether it’s custom vs canned, editable vs non-editable. 

What are the control owners’ procedures to ensure C&A. An IPE lead sheet [see video for example], is one way to obtain C&A from the control owner perspective. When the user generated in in an Excel format, how do you tackle it? One way is by including a screenshot to indicate what parameters were utilized, and if possible tying it back to a system inquiry screen to ensure that the data was complete and accurate

Compare the report to data external to the system. For instance, if I’m looking at a list of all invoices from the lenders, can I actually go into the original invoices to compare or can you compare directly to some kind of internal database? If I as an auditor can independently query the database and obtain the same results, that provides me additional comfort there.”  – Mukesh Arora 

Check out the full video for step-by-step examples, SOC report reliance considerations, IPE configuration testing, and more​​​​​​!

Looking for more thought leadership? Check out our on-demand webinar library and stay tuned for more videos featuring industry leaders and experts discussing timely issues, insights, and experiences.