A good Segregation of Duties (SoD) program establishes effective controls and policies to ensure a company is compliant to its Governance, Risk Management and Compliance (GRC) program. SoD prevents people from realizing, and accounting for, financial transactions where they have a potential role combination that can lead to fraud or errors in reporting. Given how central the SAP platform is for business management and accounting, SAP SoD tools emerge as a key success factor in building sound but cost-effective SoD controls.
Segregation of Duties: Definition and Main Concepts
Understanding SoD requires some knowledge of how businesses track their earning and spending. On the revenue side, for example, how can a business be confident that the amount of a sale booked in the general ledger and the resulting bank deposit actually match what the customer, in fact, paid?
In the “you would really be surprised” department, when there are few controls over the sales accounting processes, there lies the potential for mischief or errors. For example, let’s assume that Sally, who works in accounting at ABC Company, has the ability to enter a new customer into ABC Company’s accounting systems. She can also write, void or modify invoices. She processes the payments she receives from customers and prepares bank deposits.
Sally also closes ABC Company’s books at the end of the month and is solely responsible for generating income statements for the business. You better hope Sally is trustworthy, because she’s in a position to steal money from the company. This may not be a pleasant thing to consider, but it can happen when people are not well supervised and internal systems lack controls.
For instance, what happens if Sally sets up a corporation called Sally Jones doing business as ABC Company? She could pluck a few checks made out to the real ABC Company every month and deposit them in her corporate doppelganger. The customer won’t know—as far as they’re concerned, their check got deposited into ABC Company’s bank account. ABC Company won’t know, because Sally deleted the invoice that generated the payment in the first place. (This is based on a true story of “skimming” that went on for years and cost a business millions of dollars in fraud losses.)
How can ABC Company avoid this risk? They can segregate the duties required for each step of the sales accounting process. If Sally can create invoices, she should not be authorized to void them, for instance. If she can book a sale into the general ledger, she should not have systemic permission to prepare the bank deposit and so forth. Someone else has to have that approval authority. And, that other person may not create invoices or do any of Sally’s duties. By segregating the duties with SAP SoD tools, fraud becomes a lot harder to pull off.
SAP SoD Scenarios
SAP SoD scenarios generally involve establishing roles for users that align with certain accounting duties. In our simplified example, Sally might be assigned the role of InvoiceCreator. In SAP, users with the InvoiceCreator role can generate invoices on SAP. However, the role of DepositCreator is allowed to write bank deposits, but has no invoice generating permissions on SAP. Someone with a ReceivablesSupervisor role can void invoices, but they cannot generate income statements.
Why SoD Matters
SoD is required for compliance with regulatory schemes like Sarbanes-Oxley (SOX). SOX mandates that publicly held corporations establish, document and audit their internal controls. That way, when a public company issues its 10Q and 10K reports, investors and regulators can be confident that the numbers in them are accurate. (SOX became law after the Enron and WorldCom scandals showed that self-policed accounting and routine audits were not sufficient to produce reliable statements of financial performance.) SoD is one of the core practices underlying many controls over financial reporting.
SAP SoD Best Practices
Efficiency is one of the biggest challenges facing corporations implementing SAP SoD tools. Done wrong (e.g. having excessive reliance on manual processes) and SoD can become a cumbersome and costly undertaking. If every financial employee who is hired or re-assigned has to be put through an exhausting analysis of his or her potential duty conflicts, that will chew up a lot of IT department time. A number of best practices have emerged to keep the process efficient and on-target.
The role-based approach is a good start with SoD on SAP. The issue, though, is one of precision. While the case of Sally makes SoD understandable, reality is not always so simple. SoD in big companies, with operations and divisions spread out in different regions, or even countries, can be very difficult to set up. To be efficient and accurate, the SAP SoD tools need to be well-aligned with financial business workflows with a clear understanding of the roles involved.
The Concept of SAP Authorization
SoD on SAP is built on the concept of user authorization. Each user of an SAP landscape is authorized to do certain things. At log in, SAP will only allow the user to see data and perform tasks connected with their defined role. This might be called “system privileges” in some cases. It’s the same idea. SoD relies on narrow authorizations. If Sally’s role is InvoiceCreator, she is only authorized to see and use the invoice generation module of the SAP Business Suite. If she tries to void an invoice, the action will be blocked.
SoD and Security
SoD is different from information security, but it’s a related concept. Security also has its own types of restrictions on authorization. In the security context, user privileges determine what kind of data a user can access. They also dictate whether the user has privileges to set up or modify system configuration or user accounts. This is known as “Privileged Access Management,” and it’s absolutely critical for good security. Without it, hackers can steal data and cover their tracks easily.
SAP SoD Tools and Role Design
SAP SoD tools, along with solutions like our ControlPanelGRC, provide a welcome measure of automation and precision to the SoD process. With these tools, it is possible to analyze roles and identify SoD risks automatically. What might take an individual days, or even weeks to discover through a manual review of roles and workflows, could appear in minutes with ControlPanelGRC.
As SoD professionals know, there could be dozens of different transaction types and workflow steps that cut across many roles. To get this all straight, companies use what is known as an “SoD Matrix” to build out their rulesets. The matrix plots roles and transactions to high conflicts of duty and where there must be segregation. With the right automaton tooling, an analyst can then port the results of the matrix directly into the SAP role index. From there, a user assigned a particular role will only have permission to perform the correct, limited duties attached to the role.
ControlPanelGRC is highly customizable for SoD controls and comes out-of-the-box with many predefined rulesets. These can quickly help an organization uncover and mitigate their SoD risks. We have extensive experience with SoD on SAP and effective SAP SoD tools. Our process is proven to keep the work of defining and implementing SoD efficiency and cost-effective.