SAP Audit Prep: What to Do Before Submission
Updated: 21 hours ago
This blog post is part of a four-part series on SAP audits. You can read part two here.
Before anything gets submitted to SAP, let’s inspect the three different sets of information you’ve been asked to compile: The SAP License Audit Workbench (LAW) Report, the Self-Declaration, and the SAP Table Requests.
1. The LAW Report
This workbench comes baked into SAP products, and there are now two versions, SLAW 1 and SLAW 2, depending on what version of SLAW you are using.
There are four questions about the LAW Report we get asked frequently:
The short answer to all these questions is “yes”. To clarify, by “engines” we mean SAP applications or programs, which SAP considers engines. There are, however, some engines that require additional information, but the report does indicate engines in use and those not licensed.
These unlicensed findings happen a lot because individual SAP apps do not require license keys, so with in your SAP system, you can run many SAP products. The vendor is counting on you to true-up or purchase those products, or they’ll charge you during an audit.
Further, not all self-declared engines will be there, but some engines have indicators showing what’s in use, and you must provide these numbers.
Regarding the question about a different format, if you have something that converts XML files, you can convert it to a different format for easier viewing, or you can save the file in a different format.
Here are two screen captures from SLAW 1. You would click on the icon next to the calculator to get an overview of the number of users. You would then need to go to measurement data, create a result log, download it, and review it with your internal audit team before you transfer it to SAP.
Because this process is so cumbersome, many customers skip it, and send the results directly to SAP. However, that lead many customers to complain about sending their results to SAP without ever seeing them. In response, SAP created SLAW 2, which provides a completely different view, shown below.
With this version, if you want to see consolidated users, you go to the step that says “Results Analysis”. SAP made this workbench for two reasons: to help customers see their usage data AND to be able to say “You saw it before you submitted it; you cannot claim later on that you didn’t know what you were submitting.” In other words, you should have discovered any errors or discrepancies between entitlements and deployment (and rectified them) before submission.
So, it is essential to review this data with your audit steering committee, determine if it’s correct, and whether there’s some system clean-up needed. The problem: in many cases, the customers’ SAP admin transfers the data before anyone has a chance to review it.
SAP engines or applications that you self-declare are the only entitlements the vendor will send you in response to your requests for information. So, if you want the vendor to provide a full list of your entitlements, you must specifically ask for it upfront before the audit begins. This will provide a view of what areas might need to be trued-up.
During this exercise you should review your SAP purchase history and contracts, with an eye towards spend volume metrics. Bear in mind that sometimes, only a single division in the company is using a particular application, and a spend volume is tied to that division. Make sure that the SAP admin understands the difference between this spend volume and the whole company’s spend volume to prevent creating a huge compliance gap. This type of error is much easier to fix before submission than later. In addition, you must also make note of engines that are no longer in use.
3. SAP Table Requests
The table requests we want to focus on are the ones for development systems.
This graphic provides a small sample set, but accurately shows what these tables look like. Auditors look primarily at two areas: Dev Access (the number of developers that have an access key) compared to the number in the USR02 table in the GLGTB/ Valid to Date column. They make the assumption that all developers listed have a dev access key, and that they’re all active.
It is extremely important for the customer to examine a couple of other fields, although SAP does not make it easy to understand these field names.
Specifically, TRDAT is your last log on, and ERDAT is your creation date. These are important because they show that one user's last log on was in 2019. But because the user still has a “valid to date” in the future, that user would be counted in an audit, even though they haven't logged in in over a year. To keep them from being counted, you should change these users’ validity dates to the past.
Another pattern that we often see is developers who are brought in on a contract basis for a specific period. You can see on the graphic that their creation dates are all the same, as are their end dates.
A best practice would be to remove the dev access keys from those developers, leaving you with additional access keys for future use. But if you don’t want to remove the access keys because you bring these people in on a regular basis, you should make an effort to control their validity dates to reflect your licenses usage more accurately.
The last thing we need to caution you about is the Business Process Worksheet that is requested by SAP auditors.
We recommend that you complete this exercise as part of your internal process. This gets sent to the business process owners and it when it comes back, it shows all the ways SAP data is accessed across the organization -- directly and indirectly. Based on the information revealed, you may not want to submit this worksheet to SAP at all, and you are not legally obligated to do so.
Richard Wright is a ClearEdge Senior Manager on the Compliance and SAM team, a former SAP auditor, and an SAP expert at Accenture.
This blog post was inspired by part three of the SAP Audit Webinar Series, Before Submission. You can access the full recording to this webinar below. To learn more about SAP audits, stay tuned for part four of this series or contact a member of the ClearEdge Compliance team.