AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor
Segregation Of Duties Conflicts In SAP
A Comprehensive Reference Of Critical Incompatibilities By Business Cycle
Why Segregation Of Duties Is The Foundation Of Fraud Prevention In SAP
Segregation of duties is the internal control principle that requires the distribution of key transaction functions, specifically the initiation, authorization, recording, custody, and reconciliation of transactions, across different individuals so that no single person can complete a fraud cycle without the involvement or knowledge of another. In SAP environments, this principle is enforced through the access control framework that governs which users can execute which transactions and which authorization objects they possess.
When segregation of duties controls fail, the organization is exposed to the full spectrum of occupational fraud risks including asset misappropriation, financial statement manipulation, vendor fraud, payroll fraud, and the circumvention of approval processes that exist to protect stakeholder value. Under SOX Section 404, management must assess and report on the effectiveness of internal controls over financial reporting, and segregation of duties within the ERP system is a core component of that assessment. PCAOB Auditing Standard AS 2201 directs the external auditor to evaluate controls that are important to the auditor's conclusion about the effectiveness of internal control, and SoD controls are consistently among the most scrutinized.
The COSO Internal Control Integrated Framework of 2013 identifies segregation of duties as a key control activity, and the IIA Global Internal Audit Standards require internal auditors to evaluate the potential for fraud, including the SoD conflicts that create fraud opportunity. ISACA COBIT 2019 addresses access management and segregation of duties within its IT governance and management objectives, providing the IT control framework context for SoD evaluation.
Both automated system access through SAP transaction codes, authorization objects, and role assignments and manual tasks such as physical approvals, signature authorizations, and reconciliation sign-offs must be included in the SoD analysis. A conflict that exists only at the system level may be mitigated by a manual control, and a manual control weakness may be compensated by a system restriction, but both dimensions must be evaluated to provide a complete picture of the organization's SoD posture.
The type and number of conflicts between transactions represent a significant scoping challenge for SOX compliance. SAP's standard GRC business rule set identifies more than one hundred fifty high-risk incompatibilities, and many organizations extend this number with custom rules tailored to their specific business processes and risk profiles. In practice, understanding the specific fraud or error risk associated with each conflict is as important as identifying the conflict itself, because the risk description determines the severity rating, the mitigating control requirements, and the audit procedures that should be applied.
SAP S/4HANA And The Business Partner Impact On SoD Analysis
Organizations operating on or migrating to SAP S/4HANA must reassess their SoD conflict matrices to reflect the most significant architectural change affecting access controls: the introduction of the Business Partner concept.
In SAP ECC, customer master data and vendor master data were maintained through separate transaction families. Customer records were created and modified through XD01 (Create Customer Centrally), XD02 (Change Customer Centrally), VD01 (Create Customer in Sales and Distribution), VD02 (Change Customer in Sales and Distribution), FD01 (Create Customer in Financial Accounting), and FD02 (Change Customer in Financial Accounting). Vendor records were managed through XK01 (Create Vendor Centrally), XK02 (Change Vendor Centrally), MK01 (Create Vendor in Purchasing), MK02 (Change Vendor in Purchasing), FK01 (Create Vendor in Financial Accounting), and FK02 (Change Vendor in Financial Accounting).
In S/4HANA, all of these transactions are deprecated and replaced by a single BP (Maintain Business Partner) transaction. This consolidation has direct implications for SoD analysis. Conflicts that were previously defined between distinct customer-side and vendor-side transaction codes must now be reevaluated under the unified BP transaction, and new conflicts may emerge from the convergence of previously separate authorization objects. Additionally, S/4HANA introduces SAP Fiori applications that carry different authorization objects than their classic GUI counterparts. SoD matrices that reference only classic transaction codes without incorporating Fiori app authorizations will produce incomplete results.
The conflicts in this reference primarily cite the classic SAP ECC transaction codes, which remain relevant for the large installed base of organizations still operating on ECC and serve as the conceptual foundation for mapping equivalent conflicts in S/4HANA environments. Where the S/4HANA Business Partner transaction creates specific implications, they are noted.
Procure To Pay Cycle
The procure-to-pay cycle encompasses vendor management, purchasing, goods receipt, invoice verification, and payment processing. It is consistently the highest-risk area for SoD conflicts because it involves the creation and payment of financial obligations, the receipt and custody of physical assets, and the management of vendor relationships that can be exploited through collusion.
Vendor Master Maintenance And Invoice Processing
XK01 (Create Vendor Centrally) or XK02 (Change Vendor Centrally) combined with FB60 (Enter Incoming Invoices) or MIRO (Enter Incoming Invoice in Logistics Invoice Verification). A user who can both create or modify vendor master records and process vendor invoices could establish a fictitious vendor with bank details directing payments to an account they control, then post invoices against that vendor to generate payments through the normal payment cycle. This is the classic shell company fraud scheme and is consistently identified as one of the most critical SoD conflicts in SAP environments.
The same risk applies when vendor maintenance is performed through MK01 (Create Vendor in Purchasing), MK02 (Change Vendor in Purchasing), FK01 (Create Vendor in Financial Accounting), or FK02 (Change Vendor in Financial Accounting), combined with any invoice processing transaction. In S/4HANA, the vendor maintenance side of this conflict is consolidated under the BP (Maintain Business Partner) transaction.
Vendor Master Maintenance And Payment Processing
XK01 (Create Vendor Centrally) or XK02 (Change Vendor Centrally) combined with F110 (Automatic Payment Program) or F-53 (Post Outgoing Payments) or FCH5 (Create Manual Check). A user who can create or alter vendor master data and execute payment transactions could create a fictitious vendor or redirect an existing vendor's bank details to a controlled account, then process payments to that vendor. The payment redirection variant, in which the user temporarily changes a legitimate vendor's bank account to their own before a payment run and changes it back afterward, is particularly dangerous because the transaction records will show payments to a vendor that the organization legitimately does business with.
Vendor Master Maintenance And Purchase Order Processing
XK01 (Create Vendor Centrally) or XK02 (Change Vendor Centrally) combined with ME21N (Create Purchase Order) or ME22N (Change Purchase Order). A user who can create vendor records and create purchase orders could establish a fictitious vendor and immediately initiate purchasing transactions against that vendor, creating a complete procurement fraud cycle from vendor setup through ordering. The purchase order creates the first step in the three-way matching process that enables payment.
Purchase Requisition And Purchase Order Processing
ME51N (Create Purchase Requisition) or ME52N (Change Purchase Requisition) combined with ME21N (Create Purchase Order) or ME29N (Release Purchase Order). A user who controls both the requisition and the purchase order creation or approval could bypass the demand validation process by creating their own purchase requisitions and converting or approving them as purchase orders without independent review. This self-approval of procurement enables the user to initiate purchases for personal use or for fictitious requirements without the segregation that ensures independent evaluation of business need.
Purchase Order Creation And Goods Receipt
ME21N (Create Purchase Order) or ME22N (Change Purchase Order) combined with MIGO (Goods Movement, specifically goods receipt movement types) or MB01 (Post Goods Receipt for Purchase Order). A user who can create purchase orders and confirm goods receipt could create a purchase order for goods or services never intended to be received, then post a fictitious goods receipt to complete the three-way matching process and enable payment to a colluding or fictitious vendor. This phantom delivery scheme is one of the most commonly cited procurement fraud scenarios.
Purchase Order Creation And Invoice Processing
ME21N (Create Purchase Order) or ME22N (Change Purchase Order) combined with MIRO (Enter Incoming Invoice in Logistics Invoice Verification) or FB60 (Enter Incoming Invoices). A user who can create purchase orders and process invoices could inflate purchase order quantities or prices and process matching invoices to extract the overpayment to a colluding vendor, or could place orders at inflated prices in exchange for kickbacks and then approve the corresponding invoices.
Goods Receipt And Invoice Processing
MIGO (Goods Movement, goods receipt movement types) or MB01 (Post Goods Receipt for Purchase Order) combined with MIRO (Enter Incoming Invoice) or FB60 (Enter Incoming Invoices). A user who can confirm goods receipt and process invoices could confirm receipt of goods that were never delivered or were delivered in lesser quantity, then process the corresponding invoice to enable full payment. This circumvention of the three-way matching control is effective because the user controls both the quantity confirmation and the financial recording.
Purchasing Information Maintenance And Purchase Order Creation
ME11 (Create Purchasing Info Record) or ME12 (Change Purchasing Info Record) combined with ME21N (Create Purchase Order) or ME22N (Change Purchase Order). A user who can maintain vendor pricing conditions and create purchase orders could manipulate the pricing information records to inflate prices and then place orders at those inflated prices, facilitating kickback arrangements with colluding vendors.
Invoice Processing And Payment Execution
MIRO (Enter Incoming Invoice) or FB60 (Enter Incoming Invoices) combined with F110 (Automatic Payment Program). A user who can post vendor invoices and execute payment runs could post fictitious invoices and immediately process payment before the invoices are detected through normal review procedures. This conflict eliminates the time window during which management review or analytics could identify the fraudulent invoices before funds are disbursed.
Order To Cash Cycle
The order-to-cash cycle encompasses customer management, sales order processing, delivery, billing, and accounts receivable. SoD conflicts in this cycle enable revenue manipulation, asset misappropriation through unauthorized shipments, and the concealment of cash theft through the manipulation of customer accounts.
Customer Master Maintenance And Sales Order Processing
XD01 (Create Customer Centrally) or XD02 (Change Customer Centrally) combined with VA01 (Create Sales Order) or VA02 (Change Sales Order). A user who can create or modify customer master records and create sales orders could establish fictitious customer accounts with manipulated pricing conditions, credit limits, or payment terms and then process sales orders against those accounts. This enables the diversion of goods to unauthorized parties, the creation of fictitious revenue, and the manipulation of sales performance metrics. In S/4HANA, the customer master side of this conflict is consolidated under the BP (Maintain Business Partner) transaction.
The same risk applies through the module-specific transactions VD01 (Create Customer in Sales and Distribution), VD02 (Change Customer in Sales and Distribution), FD01 (Create Customer in Financial Accounting), and FD02 (Change Customer in Financial Accounting) when combined with sales order transactions.
Sales Order Processing And Delivery
VA01 (Create Sales Order) or VA02 (Change Sales Order) combined with VL01N (Create Outbound Delivery with Order Reference) or VL02N (Change Outbound Delivery). A user who controls both sales order creation and delivery processing could create unauthorized sales orders and alter delivery documents to confirm shipment of goods, facilitating the physical misappropriation of inventory. This conflict bypasses the control that normally exists when separate individuals are responsible for authorizing the sale and confirming that goods have left the warehouse.
Sales Order Processing And Billing
VA01 (Create Sales Order) or VA02 (Change Sales Order) combined with VF01 (Create Billing Document) or VF02 (Change Billing Document). A user who can create sales orders and generate billing documents could manipulate sales terms and immediately generate invoices that reflect the unauthorized terms. This combination enables revenue manipulation, premature revenue recognition, and the creation of side agreements that are not visible in the normal approval chain.
Sales Order Processing And Credit Memo Issuance
VA01 (Create Sales Order) or VA02 (Change Sales Order) combined with credit memo processing through order type-specific use of VA01 for credit memo requests or FB75 (Enter Accrued Revenue) or VF01 (Create Billing Document for credit memo types). A user who can create sales orders and issue credit memos could obtain goods through legitimate orders and then issue credit memos to cancel the customer's obligation, effectively obtaining goods without payment and concealing the theft or facilitating kickback arrangements.
Customer Master Maintenance And Accounts Receivable Processing
XD01 (Create Customer Centrally) or XD02 (Change Customer Centrally) combined with F-28 (Post Incoming Payments) or F-32 (Clear Customer Open Items). A user who can maintain customer master data and process incoming payments or clear customer accounts could divert incoming payments by modifying customer payment details, misapply payments to conceal theft, or clear overdue or disputed items to hide embezzlement. This combination is particularly dangerous for lapping schemes in which the user diverts a payment from one customer and covers the shortage by applying a subsequent payment from another customer.
Customer Master And Vendor Master Cross-Maintenance
XK01 (Create Vendor Centrally) or XK02 (Change Vendor Centrally) combined with XD01 (Create Customer Centrally) or XD02 (Change Customer Centrally). A user who can create both vendor and customer master records could establish linked fictitious entities on both sides of the ledger, enabling circular transaction schemes in which the organization pays a fictitious vendor for goods that are simultaneously invoiced to a fictitious customer. This creates the appearance of legitimate commercial activity while funds are diverted. In S/4HANA, this conflict is consolidated because the BP transaction manages both customer and vendor roles within a single business partner record, meaning that a user with BP access may inherently have the ability to create both customer and vendor relationships unless the authorization objects are specifically restricted.
Billing And Customer Account Clearing
VF01 (Create Billing Document) or VF02 (Change Billing Document) combined with F-32 (Clear Customer Open Items) or FBRA (Reset Cleared Items). A user who can create billing documents and clear customer accounts could issue fictitious credits or clear receivables to hide write-offs and conceal fraud. The ability to reset previously cleared items through FBRA further enables the manipulation of the clearing history.
Delivery Processing And Invoice Creation
VL02N (Change Outbound Delivery) or VL01N (Create Outbound Delivery) combined with F-22 (Enter Customer Invoice). A user who can modify delivery documents and create customer invoices could manipulate delivery quantities, dates, or receiving parties and then issue invoices that correspond to the altered delivery records, enabling billing fraud or the concealment of inventory discrepancies.
Sales Order Processing And Payment Processing
VA01 (Create Sales Order) combined with F-30 (Post with Clearing) or F-32 (Clear Customer). A user who can create sales orders and post clearing entries in accounts receivable could process fraudulent sales transactions and then manipulate the payment records by applying incoming payments to incorrect customer accounts, clearing balances prematurely, or concealing outstanding receivables.
Financial Accounting And General Ledger
The general ledger is the central consolidation point for all financial transactions and is subject to SoD conflicts that enable financial statement manipulation, unauthorized fund transfers, and the concealment of fraudulent activity through journal entry manipulation.
Journal Entry Posting And Approval
FB01 (Post Document) or FB50 (Enter G/L Account Document) or F-02 (Enter G/L Account Posting) combined with the ability to park and approve journal entries through FBV0 (Post Parked Document), or combined with FBRA (Reset Cleared Items) or FB09 (Change Line Items). A user who can both post and approve journal entries could post unauthorized entries to misstate financial results, create fictitious expenses, or transfer funds to personal accounts without independent review. This conflict is one of the most significant for financial reporting integrity because journal entries are the mechanism through which all financial adjustments are recorded.
Journal Entry Posting And Document Reversal
FB01 (Post Document) or F-02 (Enter G/L Account Posting) combined with FB08 (Reverse Document) or FBRA (Reset Cleared Items). A user who can post and reverse financial documents could post fraudulent entries to trigger follow-on processes such as payments, then reverse the entries to conceal the audit trail while retaining the benefits of the initial posting.
Journal Entry Posting And Period-End Control
F-02 (Enter G/L Account Posting) or FB01 (Post Document) combined with F.80 (Mass Reversal of Documents) or F.16 (Automatic Clearing) in conjunction with period-end functions. A user with both powerful posting capabilities and period-end control could manipulate earnings by posting and reversing large entries around the period close, inflating or deflating reported results to meet performance targets or to conceal prior-period irregularities.
G/L Account Master Maintenance And Journal Entry Posting
FS00 (Edit G/L Account Centrally) or FSP0 (Maintain G/L Account in Chart of Accounts) combined with FB01 (Post Document) or F-02 (Enter G/L Account Posting) or FB50 (Enter G/L Account Document). A user who can create or maintain general ledger accounts and post journal entries could create hidden or mislabeled accounts and then move balances to those accounts to siphon funds or hide unauthorized transactions from financial review. The ability to create new accounts provides a mechanism for concealing misappropriation that is invisible to standard account-level reporting until the hidden accounts are discovered.
Period Open And Close Combined With Journal Entry Posting
OB52 (Maintain Posting Period Variants) combined with FB01 (Post Document) or FB50 (Enter G/L Account Document). A user who can both reopen closed accounting periods and post journal entries could reopen a period that has already been closed and reported, post unauthorized entries to manipulate the prior-period financial results, and then close the period again to conceal the manipulation. This conflict directly threatens the integrity of the financial close process and is consistently identified as a high-priority conflict in SOX compliance testing.
Mass Document Reversal And Period Management
F.80 (Mass Reversal of Documents) combined with OB52 (Maintain Posting Period Variants). A user who can both reopen closed periods and execute mass document reversals could reverse previously posted entries in periods that should be locked, effectively altering financial results after the period-end close has been completed. This conflict was identified in the earlier post on the 100 most critical SoD conflicts as one of the highest-priority financial close risks.
Bank And Cash Management
Bank and treasury operations involve direct control over cash and financial assets and therefore require strict segregation to prevent the diversion of funds and the concealment of unauthorized transactions.
Bank Master Data And Payment Processing
FI12 (Change House Banks and Bank Accounts) or FI01 (Create Bank) combined with F110 (Automatic Payment Program) or F-53 (Post Outgoing Payments). A user who can maintain bank master data and execute payment transactions could redirect payment runs to unauthorized bank accounts by altering the house bank configuration, then process mass payments directed to the fraudulent accounts. This conflict enables the diversion of large payment volumes through a single configuration change.
Manual Bank Statement And General Ledger Clearing
FF67 (Manual Bank Statement) combined with F-03 (Clear G/L Account) or FEBA (Post Bank Statement). A user who can post manual bank statement entries and clear general ledger accounts could hide unauthorized withdrawals by manipulating the bank statement postings within SAP and clearing the corresponding general ledger entries to eliminate the audit trail.
Bank Reconciliation And Payment Processing
FF67 (Manual Bank Statement) or FEBA (Post Bank Statement) or FF_5 (Bank Reconciliation) combined with F110 (Automatic Payment Program) or F-53 (Post Outgoing Payments) or FCH5 (Create Manual Check). A user who can process payments and perform bank reconciliation could process unauthorized payments and then manipulate the bank reconciliation to hide the outflows, preventing detection of missing funds. This check kiting and concealment risk is one of the most consequential treasury SoD conflicts.
Bank Reconciliation And Invoice Processing
FF67 (Manual Bank Statement) or bank reconciliation functions combined with FB60 (Enter Incoming Invoices) or MIRO (Enter Incoming Invoice). A user who can both reconcile bank statements and process invoices could hide differences between bank payments and posted accounts payable records by manipulating the reconciliation to match unauthorized disbursements.
Accounts Payable Payments And Bank Reconciliation
F110 (Automatic Payment Program) or F-53 (Post Outgoing Payments) combined with FF67 (Manual Bank Statement) or bank reconciliation functions. A user who can enter unauthorized payments and perform bank reconciliation through the same person could process illegitimate payments and then conceal them by manipulating the reconciliation between the SAP records and the bank statement.
Manual Check Processing And Bank Reconciliation
FCH5 (Create Manual Check) combined with FF67 (Manual Bank Statement) or bank reconciliation functions. The same concealment risk applies when the payment is executed through manual check creation rather than through the automatic payment program. The user could create unauthorized manual checks and then manipulate the bank reconciliation to prevent the unauthorized disbursement from being detected.
Asset Accounting
The asset management cycle encompasses the creation, capitalization, depreciation, transfer, and retirement of fixed assets. SoD conflicts in this area enable ghost asset fraud, unauthorized disposal, and the manipulation of depreciation to distort financial results.
Asset Master Maintenance And Asset Acquisition
AS01 (Create Asset Master Record) or AS02 (Change Asset Master Record) combined with ABZON (Post Asset Acquisition without Purchase Order) or ABZP (Post Asset Acquisition with Purchase Order). A user who can create asset master records and post asset acquisitions could set up fictitious assets and post acquisition transactions to siphon cash from the organization. The fictitious assets appear on the balance sheet, creating artificial asset balances while the acquisition payments are directed to controlled accounts.
Asset Master Maintenance And Asset Retirement
AS01 (Create Asset Master Record) or AS02 (Change Asset Master Record) combined with ABAON (Post Asset Retirement by Sale) or ABAVN (Post Asset Retirement by Scrapping). A user with full control over the asset lifecycle from creation through retirement could write off or dispose of existing assets to hide physical theft of the underlying equipment or property, or could manipulate gains and losses on disposal to distort financial results.
Asset Master Maintenance And Depreciation Processing
AS02 (Change Asset Master Record) combined with AFAB (Post Depreciation) or AFAR (Recalculate Depreciation). A user who can modify asset master data including useful life, depreciation keys, and valuation parameters and then execute depreciation runs could artificially inflate or deflate depreciation expense and asset carrying values, manipulating both the income statement and the balance sheet.
Inventory And Materials Management
The inventory cycle encompasses material master management, goods movements, physical inventory, and inventory valuation. SoD conflicts in this area enable inventory theft, the manipulation of inventory records to conceal shortages, and the distortion of inventory valuation.
Goods Receipt And Inventory Adjustment
MIGO (Goods Movement, goods receipt movement type 101) combined with MIGO (Goods Movement, goods issue movement types 201, 261, 301, 309) or MB1A (Goods Withdrawal) or MB1B (Transfer Posting). A user who can receive goods into inventory and issue unauthorized transfer postings or goods withdrawals could receive goods and then remove them from inventory through unauthorized movements, concealing the physical theft by making the inventory records appear consistent.
Physical Inventory Count And Inventory Adjustment
MI01 (Create Physical Inventory Document) or MI04 (Enter Inventory Count) combined with MI07 (Post Inventory Differences). A user who can create physical inventory documents, enter count results, and post inventory adjustments could manipulate physical count entries to understate actual inventory quantities and then post the differences as inventory write-offs, effectively writing off inventory that the user has physically stolen.
Material Master Maintenance And Goods Movements
MM01 (Create Material) or MM02 (Change Material) combined with MIGO (Goods Movement) or MB01 (Post Goods Receipt) or MB1A (Goods Withdrawal). A user who can create or modify material master records and post goods movements could create a material as non-valuated or consumable to bypass strict tracking, then issue large quantities for personal theft. Alternatively, the user could change material valuation prices or units of measure and then move goods to exploit the price discrepancy, inflating inventory values or creating write-off opportunities.
Goods Movements And Physical Inventory
MIGO (Goods Movement) combined with MI04 (Enter Inventory Count) and MI07 (Post Inventory Differences). A user who can accept goods via goods receipts and perform physical inventory adjustments could receive goods, misappropriate them, and then manipulate the inventory count and adjustment process to conceal the resulting shortage.
Human Resources And Payroll
Payroll fraud is one of the highest-impact SoD risk areas because it involves the direct creation and modification of payment obligations and the processing of those payments. Ghost employee schemes, salary manipulation, and overtime fraud are all enabled by inadequate segregation in the HR and payroll domain.
Employee Master Data And Payroll Processing
PA30 (Maintain HR Master Data) combined with the payroll driver transaction, which varies by country but is generally PC00_M99_PAY (Payroll Driver) or the country-specific variant such as PC00_M10_CEDT (Remuneration Statement for the US). A user who can create or modify employee master records and execute the payroll run could create fictitious ghost employees with bank details directing payments to accounts they control, inflate salary or overtime data for themselves or accomplices, and then process payroll to generate the unauthorized payments.
Employee Personal Data And Bank Detail Maintenance
PA30 (Maintain HR Master Data, Infotype 0002 Personal Data) combined with PA30 (Maintain HR Master Data, Infotype 0009 Bank Details). A user with access to both infotypes could create or modify employee records and change bank routing information to redirect salary payments to their own bank account. While this involves a single transaction code, the conflict arises at the infotype authorization level, and the SoD matrix should evaluate access to specific infotypes rather than only at the transaction code level.
Time Management And Payroll Processing
CAT2 (Enter Time Sheet in CATS) or PA61 (Maintain Time Data) or PA30 (Maintain HR Master Data, Infotype 2001 Absences or Infotype 2002 Attendances) combined with the payroll driver transaction. A user who can enter time records and execute payroll could enter inflated overtime or fictitious time records for themselves or accomplices and then process the payroll to extract unauthorized payments.
Employee Master Data And Payment Execution
PA30 (Maintain HR Master Data) combined with F110 (Automatic Payment Program) or F-53 (Post Outgoing Payments). A user who can maintain employee records and execute payment runs could add ghost employees or modify bank account information and process the related payments through the financial payment process rather than through the payroll system, potentially bypassing payroll-specific controls.
Basis And Security Administration
Security administration SoD conflicts are among the most critical because they provide the mechanism through which all other SoD controls can be circumvented. A user who can grant themselves or others excessive access can defeat every business process control in the system.
User Administration And Role Maintenance
SU01 (User Maintenance) or SU10 (User Mass Maintenance) combined with PFCG (Role Maintenance) or SU02 (Maintain Authorization Profiles). A user who can create user accounts and define the roles and authorizations assigned to those accounts could create ghost user accounts, assign overly broad profiles such as SAP_ALL that provide unrestricted system access, and then log in using those accounts to commit fraud in any business module without the transactions being traced to their own user identity. This privilege escalation conflict represents the most severe SoD risk in the SAP environment because it enables the perpetrator to bypass every other control in the system.
User Administration And Business Transaction Execution
SU01 (User Maintenance) combined with any critical business transaction such as F110 (Automatic Payment Program), FB01 (Post Document), MIRO (Enter Incoming Invoice), or ME21N (Create Purchase Order). A security administrator who can create user accounts and also execute critical business transactions could create backdoor accounts for fraudulent transaction execution, bypassing the normal controls that govern access to those transactions.
Transport Management And Development
STMS (Transport Management System) or SE09 (Transport Organizer) combined with SE38 (ABAP Editor) or SE80 (Object Navigator) or SE37 (Function Builder). A user who can both develop or modify programs and release transports to production could write malicious code that modifies payment logic, creates backdoors, or alters business rules and then promote that code directly to the production environment, bypassing the testing, review, and approval processes that constitute the change management control framework. The earlier post on what SOX auditors test in SAP addressed the change management controls that prevent unauthorized code deployment, and this SoD conflict directly threatens those controls.
Client Administration And Transport Management
SCC4 (Client Administration) combined with STMS (Transport Management System) or SE09 (Transport Organizer). A user who can open the production client for direct changes and manage transports could bypass the standard three-system landscape controls by opening production for direct modification. This conflict enables unauthorized configuration or data changes directly in the live system without following the standard development-testing-production transport path.
Table Maintenance And Business Process Execution
SM30 (Maintain Table Views) or SE16N (General Table Display, when configured with edit capability) or SE11 (ABAP Dictionary) combined with any financial or logistics transaction code. A user who can modify data directly in SAP database tables and execute business transactions could bypass application-level controls, approval workflows, and audit logs by changing configuration or master data at the table level. Direct table modification is one of the most dangerous access capabilities in SAP because it operates below the application control layer and may not generate the same audit trail as changes made through standard transactions.
Configuration And System Control
Conflicts between system configuration access and business transaction execution create the risk that a user could weaken or remove control settings and then exploit the resulting gap.
System Configuration And Transaction Execution
SPRO (Customizing Implementation Guide) or configuration-specific transactions such as OB52 (Maintain Posting Period Variants), OBYC (Automatic Account Determination), or OME1 (Tolerance Limits for Price Variances) combined with business transactions such as FB01 (Post Document), MIRO (Enter Incoming Invoice), or F110 (Automatic Payment Program). A user who can modify system configuration and execute business transactions could raise tolerance limits, change approval thresholds, modify automatic account assignments, or alter posting period restrictions, then exploit the weakened controls to process unauthorized or inflated transactions. This control override risk is particularly insidious because the configuration changes may appear to be legitimate system maintenance while actually creating the conditions that enable fraud.
Single Transaction Codes With Inherent Conflicts
Some SAP transactions embed multiple sensitive functions within a single transaction code, meaning that access to the transaction alone can create SoD issues without any second transaction being involved.
F-02 (Enter G/L Account Posting) can post to vendor, customer, general ledger, and asset accounts using various posting keys within a single transaction. A user with broad F-02 access can bypass separate accounts payable, accounts receivable, and general ledger processes to post fraudulent self-balancing entries that do not pass through the normal approval workflows for each account type.
FB01 (Post Document) and FB05 (Post with Clearing) provide flexible posting and clearing capabilities that allow a user to conceal misappropriation by clearing against unrelated open items within a single transaction session.
MIGO (Goods Movement) supports multiple movement types within a single transaction, meaning a user with broad MIGO access could perform goods receipts, goods issues, transfer postings, and inventory adjustments without the segregation that would exist if these functions were assigned through separate transactions.
PFCG (Role Maintenance) allows a security administrator to create and modify roles and authorization profiles. A user with PFCG access can grant themselves or others excessive access, defeating the SoD framework that depends on appropriate role design.
MI10 (Create List of Differences with Update) and related physical inventory transactions allow a user to enter count results and post inventory differences within a single process, enabling the manipulation of inventory quantities and values to hide theft.
Mitigating Controls When Conflicts Cannot Be Eliminated
In practice, it is not always possible to eliminate every SoD conflict through access restriction alone, particularly in smaller organizations, shared service centers, or environments with limited personnel. When a conflict cannot be resolved by removing one of the incompatible transactions from a user's access profile, the organization must implement compensating or mitigating controls that reduce the residual risk to an acceptable level.
Effective mitigating controls include regular and documented review of user activity logs for the conflicting transactions, with evidence that a supervisor or independent reviewer has examined the transactions processed by the conflicted user. Transaction-level monitoring through SAP GRC Access Control or equivalent tools from providers such as Pathlock, Soterion, or SecurityBridge that flag instances where a single user has executed both sides of a conflicted transaction pair provides detective control coverage. Periodic user access reviews that confirm whether the business justification for maintaining the conflict remains valid and that the mitigating controls are functioning as intended are essential. Workflow-based approvals that require a second authorized user to approve the execution of one side of the conflict before the transaction can be completed provide a preventive layer.
The existence of a mitigating control does not eliminate the conflict from the SoD matrix. It changes the residual risk rating. The conflict should continue to be reported, monitored, and periodically reassessed to determine whether the business conditions that necessitated the exception still apply.
Maintaining The SoD Matrix As A Living Document
A segregation of duties matrix is not a static document. It must evolve with the organization's business processes, system configuration, regulatory environment, and risk appetite. Transaction codes that exist in the matrix but are not used in the organization's configuration should be reviewed for relevance. Custom transaction codes and custom programs using the Z or Y namespace should be analyzed and mapped to equivalent standard transaction conflicts where applicable. Composite and derived roles should be decomposed to identify SoD conflicts that are not visible at the individual transaction code level but emerge when roles are combined in a user's access profile.
Internal audit and access security teams should coordinate their SoD testing with the compliance function to ensure that the conflict matrix reflects current regulatory requirements and that the risk descriptions are aligned with the organization's risk taxonomy. The SoD matrix should be formally approved by process owners and reviewed at least annually, with interim updates triggered by significant system changes, organizational restructuring, or the identification of new fraud schemes relevant to the organization's SAP configuration.
Organizations migrating to S/4HANA should use the migration as the opportunity to conduct a comprehensive revalidation of the entire SoD matrix, incorporating the Business Partner consolidation, Fiori application authorizations, and the simplified data model changes that affect how access controls operate in the new environment.
From Access Control To Fraud Prevention
Segregation of duties in SAP is not merely a technical access control exercise. It is a fundamental component of the organization's fraud prevention and financial reporting integrity framework. Every conflict in the SoD matrix represents a specific fraud or error scenario that becomes possible when a single user is granted incompatible access. The risk descriptions must be precise because they inform the audit procedures, the severity ratings, the mitigating control requirements, and ultimately the management representations about the effectiveness of internal controls.
Organizations that treat the SoD matrix as a compliance checklist rather than a risk management instrument will produce access reviews that satisfy the auditor without genuinely reducing fraud exposure. The distinction between a mature SoD program and a perfunctory one lies in the quality of the risk analysis behind each conflict, the rigor of the mitigating control framework, and the commitment to keeping the matrix aligned with the reality of how the system is used.
Commonly Referenced SAP Reports And Tools For SoD Analysis
SAP and third party solutions provide many ways to support SoD analysis. Commonly referenced SAP reports include RSUSR008 Users According To Logon Date And Password Change and RSUSR009 Profiles By Complex Selection Criteria, but these reports are not substitutes for a full business risk review.
In practice, organizations often rely on SUIM User Information System, SAP GRC Access Control, and third party access governance tools to identify conflicts, emergency access, critical permissions, and role design weaknesses. These tools improve efficiency, but they do not replace the need to explain the business risk behind each conflict.
Why Manual Controls Must Be Included
A strong SoD review should not stop at SAP role analysis. Manual approvals, physical check signing, reconciliation signoff, emergency payment release, offline journal support, and workflow override authority can all change the risk materially.
This means internal audit and control teams should map SAP conflicts alongside manual authorization responsibilities. A user with limited system access may still create a conflict if they hold a compensating or approving role outside the application.
Final Perspective
The most effective SAP SoD matrices do not simply list incompatible transactions. They explain how the access combination creates a realistic path to fraud, error, concealment, or financial misstatement.
For SOX, internal audit, and SAP security teams, that is the standard that matters. The goal is not the largest rule library. It is a defensible and business relevant conflict model that helps management focus remediation where access risk is genuinely material.
References
SAP standard security and authorization practices relevant to Segregation Of Duties analysis
Institute of Internal Auditors guidance on internal control, fraud risk, and SAP related audit considerations
Committee of Sponsoring Organizations of the Treadway Commission. Internal Control Integrated Framework
COBIT guidance relevant to access governance and application control
Leading market practice in SAP GRC Access Control, SAP security design, and SOX related SoD rule management
For the complete list of high risk SOD conflicts in SAP: http://www.box.net/shared/am4bsvi8i5
CR04 Process CRM Sales Order + SD02 Delivery Processing = A user could create a fictitious sales order to cover up an unauthorized shipment.
CR04 Process CRM Sales Order + CR07 CRM Billing = Inappropriately create or change sales documents and generate the corresponding billing document in CRM.
CR05 Service Order Processing + CR06 Service Confirmation = Enter fictitious service orders for personal use and accept the services through service acceptance. The user could prompt fraudulent payments. In addition spare parts could be fraudulently issued from inventory as a result of the confirmation.
SR01 EBP / SRM Vendor Master + SR03 EBP / SRM Invoicing = Maintain a fictitious vendor and enter an invoice to be included in the automatic payment run.
FI03 Bank Reconciliation + SR03 EBP / SRM Invoicing = A user can hide differences between bank payments and posted AP records.
SR01 EBP / SRM Vendor Master + SR07 EBP / SRM PO Approval = Create a fictitious vendor or change existing vendor master data and approve purchases to this vendor.
SR01 EBP / SRM Vendor Master + SR09 EBP / SRM Maintain Org Structure = Create or maintain fictitious vendor and manipulate the organizational structure to bypass approvals or secondary checks.
AR02 Cash Application + FI03 Bank Reconciliation = Allows differences between cash deposited and cash collections posted to be covered up.
MM04 Goods Movements + MM02 Enter Counts – IM + MM04 Clear Differences – IM = Accept goods via goods receipts and perform an IM physical inventory adjustment afterwards.
MM04 Goods Movements + MM03 Enter Counts & Clear Diff - IM = Accept goods via goods receipts and perform an IM physical inventory adjustment afterwards.
PR01 Vendor Master Maintenance + AP02 Process Vendor Invoices = Maintain a fictitious vendor and enter a Vendor invoice for automatic payment.
PR01 Vendor Master Maintenance + PR02 Maintain Purchase Order = Create a fictitious vendor and initiate purchases to that vendor.
PR02 Maintain Purchase Order + MM03 Enter Counts & Clear Diff - IM = Inappropriately procure an item and manipulating the IM physical inventory counts to hide.
FI03 Bank Reconciliation + AP02 Process Vendor Invoices = Can hide differences between bank payments & posted AP records.
PR04 PO Approval + MM02 Enter Counts - IM + MM04 Clear Differences – IM = Release a non bona-fide purchase order and the action remain undetected by manipulating the IM physical inventory counts.
PR01 Vendor Master Maintenance + PR05 Purchasing Agreements = Risk of entry of fictitious Purchasing Agreements and the entry of fictitious Vendor or modification of existing Vendor especially account data.
AP01 AP Payments + FI03 Bank Reconciliation = Risk of entering unauthorized payments and reconcile with the bank through the same person.
PR02 Maintain Purchase Order + MM02 Enter Counts - IM = Inappropriately procure an item and manipulating the IM physical inventory counts to hide.
PR04 PO Approval + MM03 Enter Counts & Clear Diff - IM = Release a non bona-fide purchase order and the action remain undetected by manipulating the IM physical inventory counts
AP04 Manual Check Processing + FI03 Bank Reconciliation = Risk of entering unauthorized manual payments and reconcile with the bank through the same person.
SD01 Maintain Customer Master Data + AR01 AR Payments = Create a fictitious customer and initiate payment to the unauthorized customer.
SD01 Maintain Customer Master Data + AR05 Maintain Billing Documents = User can create a fictitious customer and then issue invoices to the customer.