Many audit issues related to SAP S/4HANA are common across organizations and could be avoided. This blog post will teach you about the most-common ones.
While this list is by no means exhaustive, at the end of this post, you should have a good understanding of the processes that commonly cause problems, and processes/changes you can enact now to avoid or minimize related issues.
Internal controls must consciously be designed—accidental control does not qualify. Unfortunately, many organizations still fail to consciously consider their business risks and design effective controls to mitigate those risks. Some organizations fail to realize that while the SAP S/4HANA system has strong capabilities for establishing effective controls, many of these controls must be turned on during the implementation.
But just enabling the controls within SAP S/4HANA is not enough—often, the default settings provided within the system are inappropriate and need to be further tuned to better match the risks of the organization. Even those that do a good job of considering current risks and controls during the SAP S/4HANA implementation process, and configuring the system accordingly with the right level of preventive and detective controls, often fail to make adjustments as business conditions change. The large majority of audit findings are actually symptoms of ineffective risk assessment and related internal control design.
Fortunately, there are some simple things you can do to avoid problems in this area.
Most non-auditors have never been trained on the basics of risk and control, and thus lack the foundation for making effective decisions related to risk and control. Many individuals find that there’s a “common sense” approach to risks and controls, once they know what to look for—they don’t need to attain an advanced degree in auditing to be risk and control savvy.
Having an agreed-on structure and process for designing and maintaining controls can go a long way to ensuring that risks have been effectively mitigated. It’s not enough to simply talk about the process you’ve developed—it must be documented (preferably in an electronic format that key employees can easily access and view) and kept up to date in a timely manner.
Enabling controls in SAP is a good first step; however, rarely do the default settings apply to your organization’s risks.
If you’re not familiar with the SAP settings that contain default values, and you don’t feel like reading detailed technical guides, a good start is to search the Implementation Management Guide (IMG) terms like “tolerance” and “default.” While this technique won’t get you to every relevant default setting, it will help you get started. If you find that many of your own SAP settings have not been changed from their defaults, then you can initiate a more comprehensive review.
Review your SAP environment periodically for business and process changes, and update your controls appropriately. Organizations that have been running SAP for a while sometimes forget that configuration, particularly around SAP configurable controls, needs to continuously evolve and should optimize over time. Also, update any process documentation that discusses these configuration decisions.
Most auditors have a view of the organization that few possess—their work allows them to see organizations in their entirety and view the complex interrelationships between processes. A common SAP S/4HANA audit finding is the result of process inconsistencies, typically in one of two categories: (1) inconsistencies within a single defined process, and (2) inconsistencies in similar processes between locations, divisions, and others.
Process differences can certainly be justified—perhaps local regulatory requirements or nuances associated with a particular product make such inconsistencies a necessity. In our experience, however, many process inconsistencies are the result of insufficient business oversight and should be avoided.
A Word of Caution about Control Variations: The right level of internal control strikes a balance between benefit (from reduced risk) and cost. As a result, organizations commonly define a robust set of controls for complex processes, and a more streamlined set of controls for lower-risk areas. When such a situation occurs within the same process (e.g., a quality assurance (QA) process where the level of testing is commiserated with the risk and complexity of the change), make sure the decision-making criteria to determine the applicable level of control is reflective of the desired outcome. We’ve seen some organizations apply QA processes based on the level of coding effort required to make the SAP S/4HANA system change—under 40 hours gets a streamlined set of testing procedures, while over 40 goes through the traditional change control and QA process. The use of hours, in this case, is fundamentally wrong. It’s possible that a complex and high-risk change can be coded in a short period of time. The right metric in this situation would be based on a complexity and risk rating rather than number of coding hours or lines of code.
A few simple things can help you avoid additional audit effort resulting from process inconsistency.
Inconsistencies within a single defined process are easy to detect and correct, typically through additional staff coaching and education.
Whether within a single process or across instances of similar processes, maintaining a list of known and approved variations will help the auditor understand and independently determine whether the variations are appropriate based on their knowledge of the business. Lack of recognition for approved process variations is almost a surefire way to receive a negative audit finding.
Often, the rationale for specific process exceptions was valid at the time it was made but no longer holds true over time (perhaps as the result of better SAP S/4HANA functionality for dealing with the cause of the variation).
The auditor will have requirements related to gathering sufficient evidence to support their conclusions. Many organizations fail to retain sufficient evidence, electronic or otherwise, and as a result put themselves in a difficult audit situation. Sometimes, the problem is the result of unclear expectations around the extent and quality of documentation. In other cases, employees followed sufficient procedures, but the evidence was not maintained long enough to be available for the audit. More important than simply maintaining evidence and other documentation, however, is to do it consistently. Often, organizations feel that if they do it most of the time, then it’s good enough. Failure to show consistent application of procedures during an audit, however, can significantly increase audit testing time and ultimately result in audit findings.
If your organization is like most, you likely have a redundant set of controls—providing greater assurance that if one control fails, another control will prevent or detect the mistake before it impacts the business. For example, if a mistake is made when entering a receiving quantity, the discrepancy detected during SAP S/4HANA’s three-way-match process is likely to trigger a review that may result in the mistake being found and corrected. It’s easy to believe that because of this control redundancy, mistakes in documentation or the application of a single control may not be important—one can just rely on other controls. Such a belief can cause significant grief during an audit, however, as failure of one control can have an exponential effect on the audit testing required (depending on the type of audit).
Auditors using sampling techniques often base their testing procedures on a statistically valid sample. Prior to selecting the sample of items (transactions, system changes, vendor records, etc.) to test, the auditor will determine the number of allowable errors in the sample. The more errors allowed in the sample, the greater the sample size must be. If errors found exceed the number of expected errors, the auditor may need to take a significantly greater sample to test. If the auditor deems the control unreliable, they may need to perform similar testing procedures on any mitigating controls (again, depending on the type of audit), and assess whether these mitigating controls are at the same level as the original control. For some mitigating controls, such as budget-to-actual reviews, the type of error that the control is likely to detect is usually significantly larger than the errors that earlier controls are intended to catch.
Documentation problems are typically easy to address by a few simple things.
Often, documentation or process steps are skipped when they become inconvenient, so being clear about the things that need to be completed at all times is critical.
A great way to ensure that a complete package of documentation and evidence is maintained according to policy is to include a review of the information as part of your normal quality assurance process.
Email authorizations, manual signoffs, and other non-SAP information likely exist outside of SAP, and having a centralized repository of this information and these images will facilitate easy retrieval if the original recipient is no longer with your organization.
Being able to tie your documentation together to show a complete process is key. An auditor performing an SAP S/4HANA change control audit, for example may want to see the authorizations and test steps used for the objects in a specific SAP S/4HANA transport. If your authorizations are organized by approver, and your test steps are organized by project number, it may be difficult to quickly associate specific approvers and project numbers to the transport reference number in which the auditor is interested.
Many organizations have a process whereby managers overseeing specific SAP-enabled functions receive a listing of users with the ability to execute transactions or run SAP Fiori apps specific to the manager’s function. Often, this list will show the manager the name of the user and the SAP role or profile they have been assigned. While this type of review can be effective for getting the “John doesn’t work here anymore” response, it’s highly ineffective as an SoD control. Most managers don’t have the depth of understanding of transactions and SAP S/4HANA security to truly validate whether the purchase order manager role contains only appropriate authorizations. Even when supplemented by transaction and authorization details associated with those roles, managers typically do not have the expertise to truly validate what they are being asked to review.
Maintaining effective SoD in SAP S/4HANA can be challenging and time consuming, particularly for organizations not using SAP Access Control or a similar security monitoring tool by a third party. Our best advice is that a specialized SoD monitoring tool is essential in any SAP S/4HANA environment. If you are not currently using one, you can put yourself in a better position if you do the following.
Many organizations struggle with SoD because they have not defined what SoD means to them, and an enterprise-wide assessment is a good first step.
This step alone helps make an SoD review more effective, allowing you to provide managers with user access by function (typically in terms that management understands), while you have the ability to tie these functions back to transactions and ultimately user roles and profiles.
Some security functions take the approach that if they send an access report to management and they do not hear back, then access must be appropriate. Clearly, this is a big assumption. Only consider access to be appropriate when a knowledgeable reviewer has indicated it’s correct.
Nothing ensures process compliance like the knowledge that one will likely be caught if they don’t follow the process.
Organizations that are serious about security take security seriously. We’ve seen organizations take user security reviews to the extreme—shutting off access for all employees where positive confirmation has not been received by the date requested by the security team. Of course, this could result in legitimate access being shut off if management is late in responding to the security review request, but it typically only takes one time being late for a manager to learn the importance of the review process.
SAP contains numerous exception processes for dealing with non-standard situations. Because of the nature of these processes, many allow certain controls to be bypassed, and organizations that do not closely restrict and monitor their use can be shocked at findings resulting from a comprehensive SAP S/4HANA audit. Entering invoices directly in financial accounting, for example, bypasses three-way match controls that may exist if the invoice were entered in materials management. Free-of-charge deliveries allow customers to be compensated for the receipt of damaged goods, but in the hands of a salesperson, could be a way to circumvent pricing policies and provide preferred customers with goods for which they are not entitled. Inventory adjustment functionality is also necessary but can compensate for poor receiving processes. While each of these functions has an appropriate use, they can also be used inappropriately.
You can strengthen controls over non-standard and exception processes if you implement these ideas.
Knowing that a typical category of transaction occurs only 1% of the time, for example, can allow you to investigate if usage frequency changes significantly from the norm.
Performing usage trending analysis at a level deeper than a mere corporate aggregate can enable you to highlight individual performance differences that can be indicative of a problem.
Even the most well-configured SAP system is subject to user error and misuse. Some of the most highly publicized implementation disasters have been exacerbated by poor user understanding of new functionality, and lack of recognition of how actions in SAP can affect other system processes. For example, a shipping clerk trying to do right for the customer and quickly get goods shipped in advance of entering the picking, packing, and shipment into SAP is actually doing the organization a disservice. Because SAP is unaware that the goods have left the facility, it loses the ability to effectively manage inventory and additionally is not initiating customer billing or accounting recognition of inventory change.
Potential audit issues associated with user education and understanding can be reduced through additional emphasis in a handful of key areas.
Simple monitoring routines that can detect issues where users are not using functionality appropriately can greatly enhance an organization’s ability to proactively identify performance problem. A clerk processing significantly more reversing entries than his peers, a location that never uses a key document type, or an overall departmental increase in calls to the help desk can all be indicators of performance problems.
Often, a fine line exists between something that’s frustrating, and something so frustrating that a user chooses to look for workarounds. The areas that users are frustrated with today are often those areas where misuse is detected during an audit.
Poorly designed training shows users how to navigate through the system. Well-designed training allows users to understand the entire process, from finding relevant information in SAP S/4HANA to understanding how to interpret it through to leveraging the system for further processing based on what they find.
The integrity of master data is paramount to SAP S/4HANA’s effective operation. Master data can affect entire categories of transactions or classifications of business partners. Unfortunately, many organizations struggle with keeping master data clean. Duplicate entries begin to appear over time. Outdated information remains active and reduces the ability to find relevant information. Data affected by business conditions, such as customer credit limits, may be set once and never revisited. Auditors often find at least one significant problem related to master data, so keeping your data management process strong is essential.
The following tips can serve as general guides for audit-proofing your master data.
Many data problems result from inconsistencies in data usage, and having a single source of control (whether it’s an individual or a committee) can ensure data quality stays high over time.
The SAP S/4HANA system contains several capabilities for validating data at entry (one of which is data validation rules); however, many of these features go unused within the typical organization.
Even when master data is entered accurately at input, certain master data can become outdated (credit limits) or irrelevant (unused vendors) over time. Audit findings can result from the continued usage of this data so ongoing data quality processes can reduce the potential for audit issues.
Editor’s note: This post has been adapted from a section of the Auditing SAP S/4HANA by Steve Biskie.