Updated June 27, 2023
How much does information produced by the entity (IPE) affect the work you do? Do you ever wish you had greater confidence in the level of documentation you have over key controls? Could you use help improving your documentation procedures?
Here we have laid out a helpful roadmap to the successful identification, evaluation and documentation of IPE in your financial reporting control environment.
When we discuss IPE with controllers and control owners, the initial reaction is usually “What is that?” or “Oh no, more work.” Though there is no sugarcoating the fact that the latter is true, the first question is an important one.
IPE is any information that is produced internally by a company being audited and provided as audit evidence, whether for use in the execution of internal controls or for substantive audit procedures performed by an external auditor. It’s good to ask:
To be able to answer these questions thoroughly, you need to understand what is considered IPE and the different risks associated with using IPE in the execution of internal controls.
Once you have identified whether IPE is being used in the execution of internal controls or as audit evidence, how do you document your consideration of the evidence sufficiently? It is important to note that different auditors may require different kinds of evidence. However, no matter who the auditor is, several key questions must always be considered and answered.
It is the control owner’s responsibility to demonstrate that the information used in the performance of a control is complete and accurate. In many cases, the individual performing the review as part of the control did not originate that data. Therefore, the reviewer must be satisfied that the presented workpaper is complete and accurate.
IPE that is subject to information technology general controls (ITGCs) does not typically require as high a level of assurance as an IPE that is not subject to ITGCs. Let’s take a closer look at the three types of IPE, from most to least risky.
An ad hoc query, which is not subject to ITGC, is the riskiest of the three types and is any nonstandard query created to produce information on an as-needed basis. It requires a great level of assurance, because the end user may use any set of parameters while generating a report. Because it is a report that has not been previously vetted or tested, it will require greater scrutiny from auditors. Without involving the auditor’s IT team, an auditor cannot verify if the parameters entered by the process owner will generate a report that is complete and accurate.
Custom reports are reports produced by the company’s in-house IT team. They are often generated when the business team requires that a certain data set be produced by the company’s enterprise resource planning (ERP) system. When an ERP system (e.g., Oracle NetSuite, QAD, Microsoft Dynamics 365, SAGE, SAP and EPICOR) lacks a standard or canned report that will satisfy the requirement, a custom report is required. The business team, therefore, works with the IT team to develop a query to produce the required result. Because this type of IPE has expected results that the business team can anticipate, it is not as risky as ad hoc queries. Custom reports are subject to normal testing and approval by the IT and business teams.
Standard or canned reports are reports that come right out of the box. They have been developed by a software company and are included with ERP systems. Canned reports are preformatted and distributed to an entire organization. The end user on the business team, and in some cases on the IT team, has little to no ability to modify or reformat these reports. Because such reports can hardly be edited, they require less scrutiny by auditors.
To document IPE properly, the process owner must first be able to answer the following questions:
Identifying the report is imperative because it dictates its risk level, which in turn dictates the level of assurance required.
Important parameters include the date range and the exclusion or inclusion of certain data. Such parameters indicate what data was pulled from the system and is the starting point of the IPE. If the data being pulled is inaccurate, the reporting and execution of the control has been compromised, and incorrect data yields inaccurate results.
Data is typically exported as PDF, Excel, CSV (commas separated values), or text files, each of which has its own characteristics. Although PDF is the least prone to manipulation, it cannot be used easily for further calculations on its own. An Excel file export is the most common format, as it allows for the use of formulas and the performance of various operations on the data.
A CSV file does not allow for operations to be performed on the data. However, because the data in a CSV file is in a tabular format, one can perform Excel-like functions on it.
Text files, which contain no special formatting, are difficult to use. It is hard to guarantee that the data was exported completely and accurately, and this problem only gets more difficult as the volume of data grows.
Such documentation might include a screenshot capturing the export details, or a copy of a report that was rerun to ensure the appropriate data has been included. When the preparer performs a control and uses certain data, it is the responsibility of the reviewer to corroborate that the data used in the execution of the control is complete and accurate. When the preparer includes a screenshot, it allows the reviewer to ensure completeness and accuracy in two ways. The preferred way is by agreeing the total dollar amount or hash total per the extract report back to the screenshot. The second way is to agree the line count of the extract report back to the screenshot.
If a screenshot was not or could not be provided due to restrictions of the system, the reviewer would need to rerun the report, which should agree to the original report used by the preparer.
If you were able to successfully agree the data to supporting documentation, then you are finished. You have ensured completeness and accuracy over the data used, and the IPE may be relied on.
However, if you were not able to agree the data to supporting documentation, and the variance cannot be explained, you must revisit the performed procedures. You may want to double-check the parameters used or investigate whether the data was manipulated incorrectly after it was extracted.
We hope you found this roadmap valuable and can begin to apply these principles in your business.
Developing IPE controls and applying best practices to stay in compliance can be a tall order for any internal team. Contact an Armanino advisor today to learn how our SOX compliance services can help you streamline the process and minimize regulatory risk.
