How to test SOX key reports for SOX compliance

Understand complexity

• Data or reports can often be very complex, therefore the testing of SOX key reports, and the auditing thereof, can also be quite complex.
• Knowing how to answer what the auditors are looking for is crucial

• There are dozens of criteria that need to be documented when testing the validity of a report
• A typical SOX Key Reports Testing template has almost 350 lines addressing over 20 topics

This sample, taken from a PWC SOX Key Report template, shows the typical beginning and end of their form.

The questions on a typical auditor’s template fall into three main categories:

Recalculation

Could the results of the report be duplicated if the same parameters were used?

Completeness

Does the report fully include the data (number of rows, or records, or amounts) within the stated parameters?

Accuracy

Does the report accurately include the data (correct dates, amounts) from the source documents within the stated parameters?

There are four main report types:

1. Standard/canned reports
   1. This type of report is preprogrammed into the software
   2. Typically, the report parameters cannot be modified by the end user, other than the date range
2. Customized
   1. These customizable reports are built in-house by your IT team or user
   2. The end user set the report data fields or parameters or wrote the script based on their specific needs
   3. When these reports are locked from further edits after they are finalized and fall under your IT general controls for change management, they can be relied upon because they undergo the normal processes for testing and approval
3. Query
   1. These are customized searches or queries built in-house by your IT team
   2. When these queries are locked from further edits after they are finalized and fall under your IT general controls (ITGC) for change management, they can be relied upon because they undergo the normal processes for testing and approval
4. Ad hoc query
   

   1. These customizable queries are also built in-house by your IT team or user
   2. The end user created the search by selecting the report fields or parameters or writing their own script on the fly
   3. These reports were not “locked down” or not subject to ITGCs and therefore require higher scrutiny if used as a Key Report or input

Document the report type

Verify the reliability of the report

Now that you know what kind of key report you have and that it is from a reliable source, you can begin to test the report and the validity of the source data.

Your documentation will include a summary of the procedures performed to assess the

• accuracy
• completeness, and
• validity of the source data.

As you can see from the example, the summary references the tabs where your exported data and reports can be found in the workbook. These tabs are where you show your work in validating the completeness and accuracy of your test.

Section C – Completeness

This is one gauge that you may overlook and assume that as long as your data is proven to be accurate, that is sufficient. Do not, however, underestimate the importance of using complete data to test your report and documenting how you validated its completeness.

In the PWC example for completeness, the following steps were taken.

• Steps 1-3 show how the data was gathered and where it is saved in the workbook.
• Step 4 describes the steps taken to verify the completeness of the data.

Step #4 is the heart of the check for completeness. Once the parameters for each report are matched and the data exported, ensuring that the same data appears in both sets of data is crucial.

In our example testing the Equity Edge Expense Allocation – Recognition report, step four was described his way:

Part of testing a key report includes mapping it to an internal control (or controls).

• It is important that your control be clearly understood by the process owner, not only in how it is designed and functions, but also in how it is documented
• This is also important for the person who documents the testing of the key controls and maps a SOX key report to an internal control