Develop an Effective SAP Automated Controls Benchmarking Strategy

Organizations are continuously working to improve their internal controls environments, increase efficiencies and reduce the cost of compliance activities. Internal controls, compliance and audit professionals are also looking to align organizations’ processes to important risk and industry trends. The Public Company Accounting Oversight Board (PCAOB) releases auditing standards that establish requirements and provide guidance on how auditors should conduct their audit of Internal Control Over Financial Reporting (ICOFR). AS 2201 (An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements) outlines an opportunity for companies to cut costs without jeopardizing compliance efforts. The benchmarking (i.e., baselining) approach for testing SAP automated controls on an ongoing basis allows an organization to reduce internal and external audit efforts and can be a critical tool for today’s SAP leaders.

Internal controls over financial reporting

Internal controls refer to those procedures within a company that are designed to reasonably ensure compliance with the company’s policies. An internal control framework should include three components – entity-level controls (ELCs), IT general controls (ITGCs) and business process controls:

• Entity-level controls represent pervasive controls, which impact the entire organization and affect the performance of preventive, detective and monitoring controls at the process or transaction level. They lay the foundation for all other components of internal control, providing both discipline and structure.
• IT general controls enable the effective and efficient testing of IT-supported business process controls. ITGCs are defined to ensure the proper development and maintenance of applications, as well as the integrity of programs and data, so that the organization can reply on the integrity of its applications.
• Business process controls are a framework of processes and control activities designed to reduce the risk of error or fraud. There should be a balance of different types of controls, including manual, automated and semi-automated. Having this blend of control types allows for an organization to take full advantage of its resources; however, it is critical to ensure that a large component of the framework is automated controls. Automated controls are system-driven, preventive controls designed to follow predetermined logic to mitigate risk by stopping issues before they occur. Within SAP, whether it be the newest version of S/4HANA or ECC 6.0, many of these automated controls are established via the SAP Customizing Implementation Guide (IMG) with the associated configuration stored in their respective tables within the application.

Here is a visual representation of a well-designed and well-balanced control framework:

Protiviti.com/wp-content/uploads/SAP-Automated-Controls1-1.jpg?resize=770%2C325&ssl=1" sizes="(max-width: 770px) 100vw, 770px" srcset="https://i0.wp.com/tcblog.protiviti.com/wp-content/uploads/SAP-Automated-Controls1-1.jpg?w=1249&ssl=1 1249w, https://i0.wp.com/tcblog.protiviti.com/wp-content/uploads/SAP-Automated-Controls1-1.jpg?resize=300%2C127&ssl=1 300w, https://i0.wp.com/tcblog.protiviti.com/wp-content/uploads/SAP-Automated-Controls1-1.jpg?resize=1024%2C432&ssl=1 1024w, https://i0.wp.com/tcblog.protiviti.com/wp-content/uploads/SAP-Automated-Controls1-1.jpg?resize=768%2C324&ssl=1 768w, https://i0.wp.com/tcblog.protiviti.com/wp-content/uploads/SAP-Automated-Controls1-1.jpg?resize=740%2C312&ssl=1 740w" alt="" width="620" height="262" />

Automated controls benchmarking 

PCAOB AS 2201 specifically outlines the benchmarking strategy for automated controls. Benchmarking can be defined as a standard point of reference against which things can be compared or assessed. While this definition is a component of the concept as it relates to automated controls, benchmarking should be considered a three-year cycle. Year one of this cycle is where the organization will be doing most of its benchmarking activities. These activities include two key aspects: back-end testing and front-end testing. Back-end testing is the assessment, definition and documentation of what configuration is established within the SAP environment. The values that are documented during back-end testing activities, if accurate and agreed upon, are effectively the benchmarked configuration. On the other hand, there is front-end testing. This is a “test of one” or positive/negative test that emulates an end-user’s process.

For example, let’s consider the three-way match functionality in the procurement and finance processes. Within SAP, back-end testing would consist of reviewing and establishing the appropriate tolerance values that the system will enforce when comparing quantities and amounts between purchase orders, goods receipts and vendor invoices. The front-end test of three-way matching in SAP would be to simulate a given step in the overall process, perform a positive and negative test and attempt to trigger the tolerance., thereby ensuring that the tolerances are operating effectively and as intended.

Provided that key IT general controls (ITGCs) over the ERP application are operating effectively, an organization may continue to rely on the benchmarked automated controls for the following year’s SOX testing. This benchmarking guidance can be found in Appendix B of AS 2201, items B28 to B33. Item B29 of the auditing standard states “…the auditor may conclude that the automated application control continues to be effective without repeating the prior year’s specific tests of the operation of the automated application control…” There are, however, some exceptions where automated controls cannot be benchmarked, typically around high-risk areas such as an organization’s revenue or other financial disclosures. This should be kept in mind when assessing if an automated control is eligible for benchmarking.

Benchmarking frequency

Although PCAOB AS 2201 does not specifically outline a timeline, three years is generally considered an appropriate frequency for re-baselining the automated controls. It is also important to re-baseline in the event of significant configuration changes in the applications. The work involved in year one can appear as a large amount of additional work when viewed in a silo. However, once the SOX testing and benchmarking activities are completed in this first year, an organization will see great benefits and time saved in years two and three. This is because the only activity required in years two and three is monitoring for configuration changes. If no changes have occurred to the benchmarked configuration, the performance of front-end testing is no longer necessary because the integrity of the control has been maintained. For instance, let’s continue with the previous three-way match configuration example. If the back-end configuration for the relevant tolerances is reviewed in year two and no changes have occurred (e.g., the percentage tolerance on the variance between invoice and purchase order quantity), then the validation of the configuration is sufficient.

Here is a visual representation of the timeline and benchmarking lifecycle:

The primary benefit of a benchmarking strategy is to reduce the amount of SOX testing over the course of a three-year period as compared to a traditional, non-benchmarked SOX framework. If the integrity of the system is appropriate, an organization may continue to rely on the benchmarked automated controls for the subsequent year’s SOX testing. The benchmarking concept offers organizations an opportunity to cut costs and reduce internal and external audit efforts without jeopardizing compliance efforts. An activity that is just as important as the benchmarking activity itself is determining the best approach and timing to conduct the benchmarking efforts. SAP S/4HANA implementation projects afford a unique opportunity to benchmark the completeness and accuracy of system configuration and system-generated reporting data (automated and semi-automated control points). Including time for these benchmarking activities will enable efficiencies, having a “designed-in” approach as opposed to retrofitting automated controls and benchmarking onto an existing framework. Thus, creating an organically designed framework that includes foundational benchmarking.