What to look for when using technology platforms in a financial audit

The growth in adoption of technology for both client and auditor has been exponential for a while now. It boggles my mind how quickly we went from substantive testing > control-based testing > automation > now AI.

Auditors have a responsibility of getting complete, accurate, and reliable information to support their audit opinion. With clients increasing the use of all forms of technology, there come challenges for an auditor in how to rely on the information being produced by this technology. While there can be different answers in how to address these challenges, the one discussed here will be through the use of System and Organization (SOC) reports.

SOC reports are designed to provide report users with information about the service organization including what the service(s) are and the control environment around them. This information allows auditors to determine how those services affect their client’s reporting (be it financial or the client's own SOC reporting). To illustrate how an auditor may use a service organization’s SOC report when performing an audit of their client, let’s look at an example.

CPA is auditing Client, who uses an accounting platform to keep all records and produce internal financial statements. Client also uses a revenue/collection software tool for sales to customers. Both of these tools are cloud-based. What are some of the risks of using those tools? They could include:

• Incomplete data (missing transactions)
• Inaccurate processing of data
• Improper integration of the two platforms
• Untimely processing or reporting functions
• Manipulation of system data

How does the CPA get comfortable with those risks being mitigated for the sake of the audit?

If both offerings have an associated SOC report that addresses these risks, then the auditor may be able to rely on those reports.

A SOC 1 report is based on internal controls over financial reporting (ICFR) and should have objectives related to both IT general controls (ITGCs), and business (or financial) processing objectives. Specifically, the CPA would want to see control objectives in Section 4 (“Control Objectives, Controls, Auditor’s Tests of Controls, Results of Tests”) that relate to how they would mitigate risks similar to above. For example, one objective may be “To determine that system processing captures all relevant transactions”.

A SOC 2 report is based on criteria that relate to specific “trust service categories” that are relevant to the service being delivered.? The five categories are: security, availability, confidentiality, processing integrity, and privacy. In our example, the CPA would like to see the categories of security, availability, and processing integrity in-scope for the SOC 2 because they would have criteria in Section 4 that relate to the risks above. Unlike SOC 1 control objectives (which are defined by service organization management), SOC 2 criteria are “set” and do not change.? Therefore, when reviewing the SOC 2 report, the CPA should also determine that the controls that address the in-scope criteria properly address the risks to the Client audit.

In either the SOC 1 or SOC 2 report, there are a few more things the CPA would read the report in order to rely on the information that the system produces. They include:

1. Read the system description (Section 3) of the report.? Make sure that the system in the SOC report is the “right” one that the Client is using. Larger companies often have multiple systems and can have different SOC reports for each of those systems. (System description article here)
2. Also in the system description, review the Complementary User Entity Controls (CUEC) section to see if there are any CUECs and what the Client has to do. CUECs are controls that the user of a system (in this case, the Client) has to have in place in order for the system to achieve its objectives. If there are any CUECs, the CPA should determine if the Client has indeed implemented these controls when using the system. Note – for many years, CUECs were a larger list of items that in reality were “user responsibilities” instead of complementary controls (as defined by the standards). More recent SOC reports have been moving these items from formal CUECs to the more informal user responsibilities. A CPA should still consider the nature of any user responsibilities listed in the system description any if they are material and relevant to the risks of the Client audit. (CUEC article here)
3. Review the independent auditor’s report (typically Section 1) and specifically note the opinion section. If the opinion is anything other than unqualified, review what caused the modification and determine if relevant and material for the Client audit.
4. Determine if there are any testing exceptions in Section 4 and if they relate to the risks the CPA noted for their Client. For example, if there are exceptions noted for the controls related to the completeness objective mentioned above, the CPA would have to determine the nature of those exceptions and if they are relevant and material to the audit risks of the Client.? If yes, the CPA may not be able to rely on the software information and perform other procedures for their audit of the Client.

In our example, if the SOC 1 or SOC 2 report is reviewed and was determined to be relevant with no exceptions, then the CPA can determine that the information being produced by the systems is going to be complete, accurate, and timely, addressing many of the Client audit risks. But the work is not done yet. The CPA would still have to determine that the correct information was being put into the system that is then being processed.? (If bad information goes in, bad information will still come out even though it was processed correctly)

The CPA should consider the Client’s controls around the “inputs” to the system. How are transactions captured, are there approvals needed, what evidence must be gathered before an entry is booked, etc. are examples of what the CPA may have to get comfortable with for the Client audit.

In our example, another form of input is the integration of the accounting system with the revenue/sales system. The CPA would want to make sure the integrations are set up and configured properly so that the correct information is being pulled by the accounting system from the revenue system. Configurations should consider things like:

1. Is the accounting system pulling from the right instance in the revenue system? (Think of a larger entity that has multiple revenue streams and maybe multiple financial reporting requirements. Making sure financial statement books A is pulling from revenue system instance A is important.)
2. Is the reporting timing from the revenue system syncing up properly with the reporting timing of the accounting system?

When a client uses a software system, an auditor has to consider the risks of using the system on the audit. Many systems have grown over the years, with a multitude of enhancements and developments to better the product. But that doesn’t necessarily mean that an auditor (and really the client) should just accept the outputs from a system. Performing the due diligence on a system when a SOC report is involved is a relatively easy and quick way for an auditor to gain confidence in the data being used for the financial statements.

Hey #cpafirms! ?? If you need outsourced help with establishing a SOC program, #peerreview (pre-review look or post-review remediation of findings or recommendations), EQCR, workpaper review, SOC-specific training, or anything else SOC-related, give me a shout! I’m happy to give back to the #CPA community and their firms, or anyone that needs additional information and guidance for the SOC space.