AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor
The most visited post in my blog covers the 20 most critical conflicts that you may find in SAP auditing, SOX testing and user security controls. After several years of fine-tuning the user conflict matrix and having SAP HANA released, I expand this post by listing the 100 most critical and frequent segregation of duties incompatibilities. This list helps in simplifying the user reviews by internal auditors, functional roles and access security professionals while explaining the risk which may result in operational fraud.
This is the list which you are welcome to get as a MS Excel file,
VA01 Create Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
F.80 Mass reversal of documents and F-60 Maintain Table: Posting Periods are incompatible since the user may open accounting periods previously closed and make postings after month end.
VA01 Create Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
F.80 Mass reversal of documents and OB52 C FI Maintain Table T001B are incompatible since the user may open accounting periods previously closed and make postings after month end.
VL02N Change outbound delivery and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
XK01 Create Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VL01N Create outbound delivery with order ref and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
VA01 Create sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK01 Create Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD02 Change customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
MIGO Goods Movement and MM01 Create Material are incompatible since the user could create or change a fictitious receipt and create/change a material document to hide the deception.
Why SAP Segregation Of Duties Still Matters
Segregation of duties remains one of the most fundamental control disciplines in SAP environments. Despite advances in ERP architecture, workflow automation, analytics, and access governance tools, the underlying risk has not changed. When a single user can initiate, modify, approve, and complete incompatible activities across a transaction flow, the organization increases its exposure to fraud, error, financial misstatement, unauthorized transactions, and control override.
This is especially relevant in SAP environments that support core business processes such as order to cash, procure to pay, record to report, treasury, inventory management, and master data administration. In these processes, poorly designed access can allow users to create fictitious counterparties, manipulate transaction records, bypass approvals, conceal unauthorized activity, or distort financial reporting.
For internal audit, SOX teams, and SAP security professionals, the challenge is not simply identifying technical access overlaps. It is determining which combinations create meaningful business risk and which should be prioritized for remediation, monitoring, or compensating controls.
Why Many SoD Matrices Are Too Large To Be Useful
One of the recurring issues in SAP access reviews is that segregation of duties matrices become too broad, too technical, or too disconnected from real business risk. Some organizations maintain thousands of rule combinations, many of which are theoretically incompatible but operationally low risk. The result is predictable. Access reviews become difficult to explain, remediation efforts lose focus, and the business begins to treat SoD alerts as administrative noise rather than control signals.
A more effective approach is to focus on critical and frequent conflicts that create a credible path to unauthorized transactions, concealment, asset misappropriation, or financial reporting distortion. This does not mean reducing rigor. It means prioritizing conflicts that matter most.
That is why a curated list of critical incompatibilities can be so valuable. It helps internal auditors, role owners, access governance teams, and control testers simplify reviews and focus attention on combinations that are both common in practice and meaningful from a fraud and controls perspective.
What Makes An SAP SoD Conflict Truly Critical
Not every incompatible transaction pair carries the same risk. A conflict becomes especially important when it allows a user to control multiple points in a process where one action can create or modify the object and a later action can approve, settle, invoice, receive, clear, or conceal it.
In practice, the highest risk conflicts often involve one or more of the following conditions. The user can create or change master data and then execute transactions against that data. The user can initiate a commercial or accounting transaction and then post, clear, reverse, or conceal the financial result. The user can create operational activity and then generate the related billing, payment, or inventory movement. The user can reopen periods, reverse postings, or alter records after normal controls should have locked the transaction history.
This is the lens that matters. The risk is not the transaction code itself. The risk is the business capability created when incompatible access is combined in one user profile.
Why SAP HANA Does Not Eliminate SoD Risk
The move to SAP HANA and more modern SAP landscapes has improved reporting speed, data access, and system capability, but it has not removed segregation of duties risk. In fact, transformation programs can sometimes increase access risk temporarily because role redesign, migration pressure, emergency access, and hybrid landscapes create new complexity.
This is an important point for audit and controls teams. SoD risk is not a legacy SAP ECC issue only. It remains relevant across modern SAP environments, including S4HANA, especially where organizations have not fully redesigned business roles, cleaned up inherited access, or integrated SoD governance into transformation.
How To Use A Critical Conflict List Properly
A list of critical incompatibilities should be used as a prioritization tool, not as a substitute for process understanding. The same conflict can present different levels of risk depending on workflow design, approval automation, system configuration, organizational structure, and the presence of compensating controls.
For example, a conflict involving customer master maintenance and order processing may be highly sensitive in a decentralized commercial model with weak approval evidence, but less severe where master data changes are tightly workflow controlled, monitored, and independently reviewed. Likewise, a transaction pair involving invoice entry and goods movement may be materially more dangerous in a high volume manual environment than in one with embedded three way match controls and exception reporting.
This is why the best SoD programs do not stop at identifying conflicts. They assess business context, user activity, role necessity, mitigating controls, and whether the access creates a realistic fraud or error scenario.
Detailed Explanation Of Critical And Frequent SAP SoD Incompatibilities
Below is a refined sample of the types of conflicts that commonly warrant close attention in SAP access reviews. The wording has been adjusted to better reflect the underlying business risk.
VA01 Create Sales Order and XD01 Create Customer Centrally should generally be segregated because a user who can create both customer master data and sales orders may be able to establish a fictitious or inappropriate customer and initiate unauthorized sales transactions. The risk is not simply disposal of assets below true value. It also includes fictitious sales activity, misdirection of goods, and concealment of unauthorized commercial arrangements.
VA01 Create Sales Order and XD02 Change Customer Centrally should generally be segregated because the user may alter customer master data and then create sales orders using manipulated terms, addresses, or related customer attributes. This can enable unauthorized transactions, diversion schemes, or improper pricing arrangements.
VA01 Create Sales Order and VD01 Create Customer Sales And Distribution should generally be segregated because a user with both capabilities may create a customer in the sales domain and then process sales transactions against that customer without sufficient independent review.
VA01 Create Sales Order and VD02 Change Customer Sales And Distribution should generally be segregated because changing customer sales data and creating orders can allow the user to manipulate commercial terms, shipping attributes, or controls relevant to the sale.
VA01 Create Sales Order and FD01 Create Customer Finance should generally be segregated because customer creation in finance combined with order processing can enable unauthorized sales and downstream receivable activity tied to improperly established customers.
VA01 Create Sales Order and FD02 Change Customer Finance should generally be segregated because the combination can allow manipulation of finance relevant customer attributes and subsequent order activity that may not reflect legitimate commercial intent.
VA02 Change Sales Order and XD01 Create Customer Centrally should generally be segregated because a user may create customer records and then modify sales orders in ways that obscure unauthorized transactions or alter commercial terms after initiation.
VA02 Change Sales Order and XD02 Change Customer Centrally should generally be segregated because control over both customer master updates and sales order changes creates a broader ability to manipulate the transaction lifecycle.
VA01 Create Sales Order and VL02N Change Outbound Delivery should generally be segregated because a user who controls both order initiation and outbound delivery changes may be able to divert goods, conceal shipment irregularities, or manipulate fulfillment records.
VL02N Change Outbound Delivery and F 22 Enter Customer Invoice should generally be segregated because the user may control both shipment related activity and customer invoicing, creating a risk of unsupported billing, duplicate billing, or concealment of unauthorized deliveries.
VL01N Create Outbound Delivery With Order Reference and F 22 Enter Customer Invoice should generally be segregated because control over both delivery creation and invoice entry creates a risk that sales fulfillment and billing records can be manipulated without independent challenge.
VF01 Create Billing Document and XD01 Create Customer Centrally should generally be segregated because a user may establish customer master data and generate billing against that customer, increasing the risk of fictitious receivables or unauthorized billing activity.
XD01 Create Customer Centrally and F 30 Post With Clearing should generally be segregated because the user may create customer records and then post and clear incoming payments, which can facilitate concealment of unauthorized transactions or manipulation of receivable balances.
XD02 Change Customer Centrally and F 30 Post With Clearing should generally be segregated because a user may alter customer data and then apply or clear payments in a way that obscures the true nature of receivable activity.
VA01 Create Sales Order and F 30 Post With Clearing should generally be segregated because the user may initiate sales activity and then influence how cash is posted or cleared, creating risk in the order to cash cycle.
VA01 Create Sales Order and F 32 Clear Customer should generally be segregated because a user may create or influence sales transactions and later clear customer items, increasing the risk of concealment of collection issues or receivable manipulation.
XK01 Create Vendor Centrally and XD01 Create Customer Centrally should generally be segregated because the same user should not normally be able to create both vendors and customers without oversight. This may allow related party style schemes, circular transactions, or use of fictitious entities on both sides of the ledger.
XK01 Create Vendor Centrally and XD02 Change Customer Centrally should generally be segregated because the ability to create vendors and alter customers can support fictitious or manipulative counterparty structures that are difficult to detect through ordinary transaction review.
MIGO Goods Movement and MM01 Create Material should generally be segregated because a user may create or maintain material records and then process goods movements that support fictitious inventory activity, conceal shrinkage, or distort stock records.
F 80 Mass Reversal Of Documents and OB52 Maintain Posting Periods should generally be segregated because a user may reopen accounting periods and reverse postings after close, which increases the risk of unauthorized post close adjustments and financial reporting manipulation.
The original post referred to F 60 Maintain Table Posting Periods in one example. That wording is inaccurate. F 60 is generally used for entering vendor invoices, while posting period control is more appropriately associated with OB52 or related configuration level access. Correct transaction references matter because weak technical precision can undermine the usefulness of an SoD rule set.
How To Use This Reference
This list identifies the most critical and frequently encountered segregation of duties conflicts across core SAP business processes, organized by process area and risk category. For each conflict, the incompatible transaction code pair is identified along with a description of the specific fraud or error risk that the combination creates.
The complete list of 100 conflicts is available for download as a structured spreadsheet for integration into access review programs, GRC platform rulesets, and audit work papers.
The conflicts in this reference should be treated as a starting point rather than a definitive and universal ruleset. Every organization must tailor its SoD matrix to its specific business processes, organizational structure, industry, and risk appetite. A conflict that is critical in one operating environment may be mitigated in another through compensating controls, organizational design, or process-specific safeguards.
Why Business Risk Descriptions Matter More Than Transaction Pairing Alone
A common weakness in SAP SoD documentation is that the stated risk is too generic, too narrow, or simply wrong. For example, saying that creating a customer and creating a sales order means assets may be disposed at less than true value captures only one possible scenario and not the most likely one in many environments.
The business risk description should explain the realistic control failure that the combination enables. Depending on the process, that may include fictitious counterparties, unauthorized sales, duplicate billing, diversion of inventory, unsupported payments, inaccurate financial reporting, manipulation of period end results, or concealment of exceptions.
This matters because the quality of the risk narrative determines whether business owners, auditors, and control committees will take the conflict seriously. Technical access rules alone rarely drive remediation. Business relevant risk articulation does.
How Internal Audit And SOX Teams Should Prioritize Review
For internal audit and SOX testing, high value SoD review should focus first on combinations that affect financially significant processes, master data integrity, period end financial controls, payment authority, and inventory movement. It should also consider whether the user actually executed both sides of the conflict, whether emergency or firefighter access was involved, whether the conflict is concentrated in sensitive populations, and whether compensating controls are formal, evidence based, and consistently performed.
This is also where analytics can improve assurance. Access risk should be connected to usage data, transactional evidence, exception history, and post close activity rather than assessed only through static role design.
What A Mature SAP Access Risk Program Looks Like
A mature SAP access risk program does not treat segregation of duties as a one time remediation project. It treats SoD as part of a wider access governance model that includes role design, provisioning controls, emergency access management, periodic access review, transaction level monitoring, and alignment with financial control objectives.
It also recognizes that some conflicts may be unavoidable in smaller populations or specialized roles. In those cases, the key question becomes whether the risk is transparent, approved, monitored, and mitigated through credible compensating controls.
Additional SAP Segregation of Duties Conflicts
Expanded Critical Conflict List
The following conflicts are organized by business process area. Each entry identifies the incompatible transaction code pair by its full SAP name, describes the specific business risk the combination creates, and explains why the access should generally not be assigned to the same user. These conflicts supplement the 21 already published and are drawn from practices documented in SAP GRC Access Control standard rule sets, ISACA SAP audit programs, and widely applied internal control frameworks.
Procure to Pay
This process area consistently produces the highest concentration of critical SoD conflicts because it involves the creation of counterparties, the commitment of organizational funds, the confirmation of goods or services received, the entry of invoices, and the release of payments. A single user with access across multiple steps in this chain can create fictitious vendors, generate unauthorized purchase commitments, confirm goods never received, enter unsupported invoices, and direct payments to accounts they control.
22. ME21N Create Purchase Order and XK01 Create Vendor (Centrally) should generally be segregated because a user who can create vendor master data and issue purchase orders may establish a fictitious vendor and direct procurement spend to that entity without independent verification.
23. ME21N Create Purchase Order and XK02 Change Vendor (Centrally) should generally be segregated because the user may alter vendor master attributes such as bank details, payment terms, or pricing agreements and then create purchase orders that exploit those changes.
24. ME21N Create Purchase Order and FK01 Create Vendor (Accounting) should generally be segregated because creating a vendor in financial accounting and issuing purchase orders against that vendor combines counterparty creation with procurement commitment in a way that bypasses standard approval separation.
25. ME21N Create Purchase Order and FK02 Change Vendor (Accounting) should generally be segregated because changing vendor financial attributes such as bank routing information and then processing purchase commitments creates a path to payment diversion.
26. ME21N Create Purchase Order and MK01 Create Vendor (Purchasing) should generally be segregated because creating a vendor in the purchasing view and issuing orders against that vendor allows a single user to control both counterparty setup and procurement activity.
27. ME21N Create Purchase Order and MK02 Change Vendor (Purchasing) should generally be segregated because a user may modify vendor purchasing data such as order currency, incoterms, or planned delivery time and then create orders that benefit from those modifications.
28. ME21N Create Purchase Order and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user who can both commit the organization to a purchase and approve the related invoice controls two of the three elements in the standard three-way match, weakening the control over unauthorized or fictitious procurement.
29. ME21N Create Purchase Order and MIGO Goods Movement should generally be segregated because a user may create a purchase order and then confirm receipt of goods or services without independent verification, enabling fictitious receipt schemes.
30. ME21N Create Purchase Order and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the user may create a procurement commitment and directly process payment, bypassing invoice verification and payment approval controls.
31. ME21N Create Purchase Order and F110 Automatic Payment Program (Parameters) should generally be segregated because a user who can create purchase commitments and configure or execute automatic payment runs may direct funds to unauthorized vendors or accelerate payments outside normal processing cycles.
32. ME51N Create Purchase Requisition and ME21N Create Purchase Order should generally be segregated because a user who can both request and approve a purchase bypasses the core separation between demand origination and procurement commitment.
33. ME21N Create Purchase Order and ME29N Release Purchase Order should generally be segregated because a user who can both create and release a purchase order effectively self-approves procurement transactions, eliminating the independent review that purchase order release is designed to provide.
34. MIRO Enter Incoming Invoice (Logistics Invoice Verification) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because a user who can enter vendor invoices and process payments may create and pay fictitious or inflated invoices without independent review.
35. MIRO Enter Incoming Invoice (Logistics Invoice Verification) and F110 Automatic Payment Program (Parameters) should generally be segregated because the user may enter invoices and then configure or trigger payment runs that process those invoices automatically, bypassing payment approval workflows.
36. XK01 Create Vendor (Centrally) and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user may create a vendor and immediately enter invoices against it, supporting a fictitious vendor and invoice scheme.
37. XK01 Create Vendor (Centrally) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the user may create a fictitious vendor and directly process payments to it.
38. XK01 Create Vendor (Centrally) and F110 Automatic Payment Program (Parameters) should generally be segregated because a user who can create vendors and configure or execute automatic payments may establish fictitious payees and trigger disbursement without manual intervention.
39. FK01 Create Vendor (Accounting) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the combination allows vendor creation in the accounting view and direct payment processing, bypassing procurement and invoice verification entirely.
40. FK01 Create Vendor (Accounting) and F110 Automatic Payment Program (Parameters) should generally be segregated because a user may create vendor accounting records with specific bank details and then process automatic payments directed to those accounts.
41. MIGO Goods Movement and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user who can confirm goods receipt and approve the related invoice controls two verification points in the procurement cycle, weakening the control that independent confirmation is designed to provide.
42. ME22N Change Purchase Order and MIGO Goods Movement should generally be segregated because a user may modify purchase order quantities, prices, or delivery terms and then confirm receipt against the altered order, concealing discrepancies.
43. MR8M Cancel Invoice Document and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user who can cancel and reenter invoices may manipulate invoice records to alter amounts, redirect payments, or conceal duplicate processing.
44. XK02 Change Vendor (Centrally) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the user may change vendor bank details and then process payments to the revised account, enabling payment diversion fraud.
45. XK02 Change Vendor (Centrally) and F110 Automatic Payment Program (Parameters) should generally be segregated because changing vendor payment attributes and triggering automatic payments creates a risk of undetected payment redirection.
46. ME22N Change Purchase Order and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user may alter purchase order terms and then enter invoices that match the revised terms, concealing unauthorized modifications to procurement commitments.
Record to Report and Financial Accounting
Financial accounting conflicts create risk when a user can both generate accounting entries and control the infrastructure that governs how those entries are processed, reversed, reclassified, or reported. Period management, document reversal, and general ledger master data maintenance are among the most sensitive capabilities in SAP financial accounting.
47. FB01 Post Document and FB08 Reverse Document should generally be segregated because a user who can both post and reverse accounting entries may create and then conceal unauthorized transactions, manipulate account balances, or alter the financial record after the fact.
48. FB01 Post Document and FS00 Edit G/L Account Centrally should generally be segregated because a user who can create or modify general ledger accounts and post journal entries may establish accounts designed to hide unauthorized activity or misclassify transactions.
49. F-02 Enter G/L Account Posting and FB08 Reverse Document should generally be segregated because the combination allows a user to post and reverse general ledger entries, creating the ability to manipulate balances temporarily or permanently.
50. F-02 Enter G/L Account Posting and FS00 Edit G/L Account Centrally should generally be segregated because the user may modify the chart of accounts structure and then post entries that exploit those modifications.
51. FB01 Post Document and OB52 Maintain Posting Period Variants should generally be segregated because a user who controls both posting capability and period access may reopen closed periods and make unauthorized post-close entries that affect financial reporting.
52. F-02 Enter G/L Account Posting and OB52 Maintain Posting Period Variants should generally be segregated because the combination creates the same period manipulation risk as the previous conflict, applied to manual general ledger postings.
53. FB50 Enter G/L Account Document and OB52 Maintain Posting Period Variants should generally be segregated because the simplified posting transaction combined with period control allows unauthorized entries into periods that should be locked.
54. F-43 Enter Vendor Invoice and F-53 Post Outgoing Payments (Vendor) should generally be segregated because a user who can enter vendor invoices directly in financial accounting and process payments controls both sides of the disbursement process.
55. F-43 Enter Vendor Invoice and F110 Automatic Payment Program (Parameters) should generally be segregated because the user may enter invoices and then trigger automatic payment processing, bypassing manual payment review.
56. FK01 Create Vendor (Accounting) and F-43 Enter Vendor Invoice should generally be segregated because a user may create a vendor in financial accounting and immediately enter invoices against it without procurement involvement.
57. F-44 Clear Vendor and F-43 Enter Vendor Invoice should generally be segregated because the user may enter vendor invoices and clear open items in a way that conceals discrepancies, duplicate payments, or unauthorized charges.
58. F-28 Post Incoming Payments and FD01 Create Customer (Accounting) should generally be segregated because a user who can create customer records and post incoming payments may manipulate receivable balances or misapply cash receipts.
59. F-28 Post Incoming Payments and FD02 Change Customer (Accounting) should generally be segregated because changing customer financial attributes and posting payments creates a path to receivable manipulation and misapplied collections.
60. FB08 Reverse Document and OB52 Maintain Posting Period Variants should generally be segregated because a user may reopen accounting periods and reverse previously posted documents, directly undermining period-end financial controls and the integrity of closed-period financial statements.
61. FB01 Post Document and F.80 Mass Reversal of Documents should generally be segregated because a user who can post accounting documents and perform mass reversals may systematically alter financial records at scale, creating significant financial reporting risk.
Asset Management
Asset accounting conflicts create risk when a single user can control the creation of asset master records and the transactions that acquire, transfer, revalue, or retire those assets. The primary concern is that assets may be created fictitiously, retired prematurely, transferred without authorization, or disposed of at manipulated values.
62. AS01 Create Asset Master Record and ABAVN Asset Retirement by Scrapping should generally be segregated because a user who can create asset records and retire assets by scrapping may record fictitious assets and then write them off, or prematurely retire legitimate assets to conceal misappropriation.
63. AS01 Create Asset Master Record and ABAON Asset Retirement from Sale with Customer should generally be segregated because the user may create asset records and process asset sales, creating a path to dispose of assets at manipulated values or to fictitious buyers.
64. AS02 Change Asset Master Record and ABAVN Asset Retirement by Scrapping should generally be segregated because modifying asset master attributes and then retiring assets allows manipulation of asset values, useful life, or location data to conceal unauthorized disposals.
65. AS01 Create Asset Master Record and AB01 Create Asset Transaction (Post Asset Transaction) should generally be segregated because a user who can create asset records and post asset transactions may record fictitious acquisitions, transfers, or revaluations.
66. AS02 Change Asset Master Record and ABAON Asset Retirement from Sale with Customer should generally be segregated because the user may alter asset values or categorization and then process asset sales that do not reflect the true condition or worth of the asset.
67. AS01 Create Asset Master Record and F-90 Acquisition from Purchase with Vendor (Asset Posting from Purchasing) should generally be segregated because the user may create asset records and post acquisition transactions tied to vendor invoices, enabling fictitious asset capitalization.
Order to Cash — Additional Conflicts
The existing list covers many core order-to-cash conflicts. The following additional combinations address billing manipulation, cancellation and re-creation schemes, and payment processing risks that are commonly encountered in sales environments.
68. VA01 Create Sales Order and VF01 Create Billing Document should generally be segregated because a user who controls both order initiation and billing document creation may generate invoices that do not correspond to legitimate sales activity or that reflect manipulated terms.
69. VA02 Change Sales Order and VL02N Change Outbound Delivery should generally be segregated because a user who can modify both sales orders and deliveries may alter quantities, delivery addresses, or terms across both documents to conceal diversion or unauthorized shipments.
70. VF01 Create Billing Document and F-28 Post Incoming Payments should generally be segregated because a user who controls both billing and cash receipt posting may generate invoices and apply payments in ways that conceal collection issues or misapply customer funds.
71. VF01 Create Billing Document and F-30 Post with Clearing should generally be segregated because the user may bill customers and then clear the resulting receivable items, concealing the true status of collections or manipulating aging reports.
72. VF01 Create Billing Document and VD01 Create Customer (Sales and Distribution) should generally be segregated because a user may create customers in the sales domain and generate billing documents against them, supporting fictitious revenue schemes.
73. VF01 Create Billing Document and VD02 Change Customer (Sales and Distribution) should generally be segregated because the user may modify customer sales data and then create billing documents that exploit those modifications.
74. VF01 Create Billing Document and FD01 Create Customer (Accounting) should generally be segregated because combining billing authority with customer financial master creation increases the risk of fictitious receivable activity.
75. VF01 Create Billing Document and FD02 Change Customer (Accounting) should generally be segregated because the user may alter customer financial terms and generate billing that reflects those altered conditions.
76. VF11 Cancel Billing Document and VF01 Create Billing Document should generally be segregated because a user who can cancel and recreate billing documents may manipulate invoice records, alter billing amounts, or conceal credit and rebilling activity.
77. VF02 Change Billing Document and F-28 Post Incoming Payments should generally be segregated because the user may modify billing records and then apply payments in a manner that conceals the changes or misrepresents the collection status.
Inventory and Warehouse Management
Inventory and warehouse transaction conflicts are especially important in manufacturing, distribution, and retail environments where physical goods movement represents a significant portion of organizational assets and cost of goods sold.
78. MB1A Goods Issue and MB1C Other Goods Receipts should generally be segregated because a user who can issue goods out of inventory and record goods receipts may manipulate stock balances, conceal shrinkage, or create fictitious inventory movements.
79. MB1A Goods Issue and MM02 Change Material (Master) should generally be segregated because the user may alter material master attributes such as valuation class, price, or unit of measure and then issue goods using the manipulated data.
80. MIGO Goods Movement and MM02 Change Material (Master) should generally be segregated because modifying material master records and processing goods movements creates a risk of inventory valuation manipulation and concealment of unauthorized stock changes.
81. MB1B Transfer Posting and MM01 Create Material (Master) should generally be segregated because a user may create material records and then process transfer postings to move inventory between locations or valuation areas without proper authorization.
82. MB1A Goods Issue and MIGO Goods Movement should generally be segregated in environments where MIGO is used for goods receipt because a user who can both issue and receive goods may execute circular inventory movements to conceal shortages or misappropriation.
Human Resources and Payroll
Human resources and payroll conflicts are among the most sensitive in any organization because they directly involve employee compensation. A user who can modify employee master data and influence payroll processing may create ghost employees, alter compensation, redirect payments, or manipulate tax and benefit deductions.
83. PA30 Maintain HR Master Data and the country-specific payroll transaction (such as PC00_M10_CALC Run Payroll for the United States or the equivalent for other country versions) should generally be segregated because a user who can change employee bank details, pay rates, or tax data and also run payroll calculations may alter compensation and process payments without independent review.
84. PA40 Personnel Actions and the country-specific payroll transaction should generally be segregated because a user who can execute personnel actions such as hiring, termination, or organizational reassignment and also process payroll may create or terminate employees and manipulate the related payroll activity.
85. PA30 Maintain HR Master Data and F110 Automatic Payment Program (Parameters) should generally be segregated because a user who can modify employee bank account information in HR master data and also configure or execute automatic payment processing may redirect payroll disbursements.
86. PA30 Maintain HR Master Data and PU00 Delete Payroll Results should generally be segregated because a user who can alter employee data and delete payroll calculation results may conceal evidence of unauthorized compensation changes.
87. PA30 Maintain HR Master Data and FB01 Post Document should generally be segregated because combining HR master data maintenance with general ledger posting capability may enable a user to create or alter employee records and post related accounting entries without separation between the HR and finance functions.
Basis and Security Administration
Basis and security conflicts are fundamentally different from business process conflicts because they involve access to the infrastructure that controls all other access. A user with combined basis and security capabilities may grant themselves or others unauthorized access, modify system behavior, alter data directly at the table level, or undermine the integrity of the authorization framework itself. These conflicts are relevant to IT general controls under SOX and to the access governance requirements of virtually every audit and compliance framework.
88. SU01 Maintain Users (User Maintenance) and PFCG Role Maintenance should generally be segregated because a user who can both create or modify user accounts and design or assign authorization roles can effectively grant any level of access to any user, including themselves, without independent review.
89. SU01 Maintain Users (User Maintenance) and SE16 Data Browser should generally be segregated because a user who can modify user accounts and directly browse database tables may access sensitive data across the entire system without application-level authorization controls.
90. SU01 Maintain Users (User Maintenance) and SM30 Maintain Table Views (Call View Maintenance) should generally be segregated because the combination allows a user to modify access controls and directly alter configuration or master data at the table level, bypassing all transaction-level controls.
91. SU01 Maintain Users (User Maintenance) and SA38 Execute ABAP Reporting (ABAP Reporting) should generally be segregated because a user who can maintain user accounts and execute ABAP programs may run reports or utilities that bypass standard authorization checks.
92. SU01 Maintain Users (User Maintenance) and SE38 ABAP Editor should generally be segregated because the combination allows a user to modify user access and alter program code, creating a path to embed unauthorized logic or bypass controls within the system.
93. SE38 ABAP Editor and SA38 Execute ABAP Reporting (ABAP Reporting) should generally be segregated because a user who can modify programs and immediately execute them may alter system behavior, extract data, or bypass controls without detection.
94. PFCG Role Maintenance and SU10 Mass User Maintenance (User Mass Maintenance) should generally be segregated because a user who can design roles and assign them in bulk may grant widespread unauthorized access rapidly, undermining the entire authorization model.
95. SE16 Data Browser and SM30 Maintain Table Views (Call View Maintenance) should generally be segregated because a user who can both view and modify table data directly has the ability to alter virtually any system record — including financial data, master data, and configuration — without using controlled transactions.
96. SU01 Maintain Users (User Maintenance) and SCC4 Client Administration should generally be segregated because a user who controls user access and client-level settings may modify client parameters that affect system behavior across the entire environment.
97. STMS Transport Management System and SE38 ABAP Editor should generally be segregated because a user who can modify program code and transport changes into production may introduce unauthorized system changes without independent technical review.
98. SM37 Background Job Overview (Job Overview) and SA38 Execute ABAP Reporting (ABAP Reporting) should generally be segregated because a user who can schedule and manage background jobs and execute programs may run unauthorized processes outside of normal business hours or monitoring visibility.
99. SE16N General Table Display and SU01 Maintain Users (User Maintenance) should generally be segregated because SE16N in some system configurations permits data modification at the table level, and combining this with user maintenance creates the same infrastructure-level risk as SE16 combined with SU01.
100. SU01 Maintain Users (User Maintenance) and SM21 System Log Analysis should generally be segregated because a user who can modify user accounts and access or manage system logs may alter access and then suppress or manipulate the log evidence that would normally detect the change. While SM21 is primarily a display transaction, in some configurations and when combined with other basis access, it can be part of a broader pattern of evidence management risk.
Technical References and Authoritative Sources
The following references support the conflict identification and risk descriptions in this list. Organizations building or validating their own SoD rule sets should consult these sources for detailed technical guidance.
SAP GRC Access Control Rule Set. SAP delivers a standard segregation of duties rule set with its GRC Access Control product. This rule set contains predefined risk definitions, functions, and conflict rules organized by business process. It serves as the baseline for most SAP SoD programs and is documented in the SAP Help Portal under SAP GRC Access Control configuration guides. Organizations should review and tailor this rule set to their specific environment, as the standard rules may not reflect all organization-specific risks.
SAP Security and Authorizations (SAP Press). The SAP Press publication on SAP security provides detailed guidance on authorization object design, role construction, user administration, and segregation of duties. It is widely used by SAP security teams and auditors as a technical reference for understanding how SAP authorization checks operate and how access conflicts arise at the authorization object level, not just the transaction code level.
SAP Help Portal — Transaction Code Documentation. SAP maintains official documentation for each transaction code, including its purpose, associated authorization objects, and configuration prerequisites. This documentation is the authoritative source for confirming the correct full name of each transaction code and understanding its functional scope. It is accessible through the SAP Help Portal and through transaction SE93 (Maintain Transaction Codes) within the SAP system itself.
ISACA — IT Audit Framework and SAP Audit Programs. ISACA publishes audit and assurance programs for ERP environments, including SAP-specific guidance on access controls, segregation of duties, and IT general controls. These programs are widely referenced by internal audit functions and external auditors performing SOX testing and operational audits of SAP environments.
COSO — Internal Control — Integrated Framework (2013). The COSO framework establishes the foundational principles for internal control design, including the principle that organizations should segregate incompatible duties or implement alternative controls where segregation is not practicable. This framework provides the conceptual basis for SoD requirements and is referenced by the SEC and PCAOB in the context of internal control over financial reporting.
PCAOB Auditing Standard AS 2201 — An Audit of Internal Control Over Financial Reporting. AS 2201 requires auditors to evaluate the design and operating effectiveness of internal controls, including IT general controls and application controls in ERP systems. Segregation of duties is a core component of this evaluation, particularly for financially significant processes and systems such as SAP.
IIA Global Technology Audit Guides (GTAGs). The Institute of Internal Auditors publishes technology audit guides that address IT governance, access management, and application controls. GTAG 8 on auditing application controls and GTAG 1 on information technology risk and controls are directly relevant to SAP SoD assessments.
SAP Note References. SAP publishes notes and knowledge base articles that address specific authorization risks, critical authorization objects, and recommended segregation practices. Key notes related to critical authorizations include SAP Note manufacturers publish security notes and authorization guides that should be reviewed as part of SoD program maintenance. The SAP Security Notes index and the SAP Community Wiki on GRC best practices provide additional practitioner-contributed guidance.
Final Perspective
The most effective SAP SoD matrices are not the largest. They are the ones that best translate technical access conflicts into meaningful business risk. For internal auditors, SOX teams, and SAP security professionals, the goal should be to identify the combinations that create the clearest path to fraud, error, or reporting distortion and to focus remediation where it matters most.
A refined list of critical and frequent conflicts can be a powerful tool for that purpose, but only when it is maintained carefully, technically accurate, and grounded in real process risk rather than generic access theory.
If useful, this list can also be structured into an Excel based conflict matrix for review, rule maintenance, and testing support.
References
AP Help Portal: official transaction, process, and authorization documentation for SAP ECC and SAP S/4HANA
SAP GRC Access Control documentation: ruleset and access risk analysis concepts
SAP PRESS publications on SAP Security, Authorizations, and GRC Access Control
COSO Internal Control – Integrated Framework for segregation of duties and control design principles
Institute of Internal Auditors (IIA) guidance on fraud risk and internal controls
ISACA guidance on access governance, SoD, and control monitoring
PCAOB and SOX internal control expectations relevant to financial reporting and access risks
Internal SAP system analysis using SUIM, PFCG, SU24, STAUTHTRACE, and transaction usage reviewSAP transaction and authorization design practices relevant to SoD and access governance
Institute of Internal Auditors guidance on internal controls and fraud risk
Committee of Sponsoring Organizations of the Treadway Commission. Internal Control Integrated Framework
US Securities and Exchange Commission and PCAOB expectations relevant to internal control over financial reporting under SOX
Access governance and SoD practices commonly used in SAP security and audit programs
Get the latest in corporate governance, risk, and compliance on Twitter