What’s that T-code really doing?
In SAP, access is controlled by governing what t-codes can be executed by various user. The careful assignment of appropriate, but not excessive access to individuals in your business helps guarantee that information is controlled. A common challenge in SAP access security is understanding what the t-codes are actually doing in the background of your SAP environment. Some t-codes are more than they appear on the surface. SAP t-codes that seem innocuous may have the ability to call other transactions that pose more risk to the accuracy of your financial statements.
For example, in a previous organization, we detected standard and custom t-codes, that were able to call fb05 in the background. The company regularly audited SAP journal entries executed through t-code fb05, only to realize that there were additional, uncatalogued t-codes added throughout the year via patches and/or the company’s software development lifecycle (SDLC), which call that transaction.
So some t-codes call transactions, but you can still have an audit report, right?
Well, yes and no. SAP’s transaction log will show you every time that a particular t-code was executed, whether that transaction was executed by an individual directly or whether it was called. That called transaction can come from a native t-code in SAP, a custom t-code built specifically for your business, or a partner application that is integrated. When running a transaction log of fb05, we often were attempting to pare down the scope of how many and by whom those transactions had to be reviewed. Under a certain threshold, most transactions are determined to be immaterial and not subject to a necessary review, or at least multiple reviews. That made it difficult to determine the source of many small dollar value postings. In one particular instance, our treasury application was calling fb05 directly through an integration for small amounts on a regular basis. The risk was that the t-code used by this application to call fb05 was also open to manual manipulation, allowing for the possibility of individuals to record manual journal entries directly to our balance sheet without detection. Even with all of this, some of these integrations or called transactions might not show up on your transaction logs of fb05.
Why would instances where a t-code is used, not show up on the transaction logs?
The discussion above refers primarily to instances of a seemingly innocuous t-code calling on a more risky t-code. There is also a possibility that instead of calling the t-code, the function or partner application calls the underlying Business Application Programming Interface (BAPI) that is used in the standard t-code. In an attempt to audit by running transaction logs, these instances will not be reported, due to the fact that they are calling the BAPI without executing the actual t-code. This is particularly risky and the reason that you need to be able to analyze access and segregation of duties (SOD) in SAP down to the authorization object level. These are commonly found in custom t-codes, usually identified with a Z or a Y prior to the standard t-code.
I’ve definitely seen those before, why do all of my t-codes begin with a Z?
There is often a motivation to develop t-codes that do exactly what you need them to do and over customize your SAP instance. The issue in doing so, is that many of those Z t-codes might be calling very risky processes and directly impacting your financial statements without your knowledge. They may be calling BAPI’s and generating changes that are not approved and instead should be directed to management prior to execution. Designing proper segregation of duties, limiting sensitive access transactions down to the authorization object level, and continuing to monitor these important foundational elements in a regular fashion, is the key to preventing these common challenges from popping up in your business.
Fastpath’s Custom Code Checker was developed exactly for this purpose, ultimately to guarantee that your company’s ruleset, or the transactions that are considered risky on their own plus those that should not be combined with other transactions, is complete and accurate. The Custom Code Checker detects transactions, BAPI’s, or other functionality that is considered risky, which is being created from a custom piece of code. This helps companies to create a catalog of where their customizations exist and what function they truly perform allowing risk to mitigated down to the acceptable level.
Want to see how it works? Schedule a demo.