Key Takeaways
- These 10 SAP SoD conflicts in manufacturing represent the highest fraud and compliance risk in any SAP environment.
- Each allows a single user to initiate and complete a financially or operationally sensitive transaction without independent oversight.
- Cross-functional combinations — where access spans two separate business processes — are the hardest to detect and the most likely to appear in audit findings.
- Finding a conflict is only the first step; the control objective is to prevent it, remediate it, and retain evidence of every decision made along the way.
An SAP Segregation of Duties (SoD) conflict occurs when a single user holds access to two or more SAP functions that should be kept separate — because combining them allows that user to initiate, approve, and complete a financially or operationally sensitive transaction without any independent check.
In manufacturing, SAP access risk is highest where access spans two different business processes, giving one person the ability to create the conditions for fraud and then execute it, approve it, or conceal it. These dangerous SAP role combinations are the defining characteristic of the most serious SAP SoD conflicts manufacturing security teams face.
Why cross-functional SAP access risks are the most dangerous
Cross-functional conflicts are the most dangerous because they give one user both sides of a transaction across two separate business processes — an exposure no single-module review will ever surface.
Most conversations about SAP access focus on individual modules — Finance, Procurement, HR. The real risk sits at the boundaries between them.
A user who can both create a vendor record and execute a payment run does not need to compromise any additional account or bypass any additional control. They hold both sides of the transaction. The same logic applies across production, quality, payroll, and plant maintenance: when setup and execution — or request and approval — sit with the same user, the separation the entire control structure depends on collapses.
This is what makes dangerous SAP role combinations categorically more severe than same-module access issues. They are harder to detect because no single module review will surface them. They cross team ownership boundaries. And they are the first thing a forensic auditor looks for after a fraud incident.
SAP in manufacturing is not just an ERP system — it is the operational backbone for finance, procurement, production, quality, plant maintenance, HR, and logistics. The number of cross-functional conflicts is significantly higher than in most other industries, and the consequences extend from financial loss to quality failures to regulatory findings.
The 10 most dangerous SAP SoD conflicts in manufacturing
Every conflict below shares the same trait: it lets one user both set up and execute a financially or operationally sensitive transaction, with no independent check in between.
1. Create vendor master + execute payment run
A user who can add a new supplier and trigger the payment run can introduce a fictitious vendor — or redirect payments to a controlled account — and release funds without independent review. This is the most financially material conflict in any manufacturing SAP environment. Vendor creation and payment execution are typically owned by different teams, so neither team's internal review catches the combined exposure.
2. Create purchase order + approve purchase order
A user who can both raise and approve a purchase order can commit company funds without any separation between request and authorization. This combination frequently persists in smaller plants as a practical workaround and is often missed in role-level reviews that do not map authorization objects. It ranks among the most common fraud paths that segregation of duties in SAP is designed to prevent.
3. Post goods receipt + process invoice verification
Three-way match — purchase order, goods receipt, and invoice — is a foundational procurement control. A user with both MIGO and MIRO access can bypass it entirely, approving payment for goods that were never delivered. The individual T-codes look unremarkable in isolation; the conflict only surfaces when both are assigned to the same user.
4. Maintain bank master data + initiate bank transfer
A user who can change supplier or employee bank account details and also initiate outgoing transfers can redirect payments to an account they control. Bank detail changes are low-volume and low-visibility in any SAP environment — they rarely trigger the same review attention as large purchase orders — making this one of the highest-severity SAP access risks in manufacturing.
5. Modify bill of materials + release production order
A user who can alter a bill of materials and release the production order can introduce unauthorized component substitutions affecting product cost, quality certification, and regulatory compliance. This conflict is invisible in a role-name review; it requires mapping to the underlying authorization objects.
6. Create production order + confirm production order
A user who can both open and confirm a production order can record fictitious manufacturing activity — booking costs to cost centers, consuming materials on paper, and posting output that was never produced. In high-volume SAP environments, a small number of fictitious confirmations are difficult to identify in the volume.
7. Record inspection results + post usage decision
Quality management in SAP depends on separating the person who records test results from the person who makes the release decision. A user who holds both functions can fabricate inspection results and approve the usage decision — releasing nonconforming product based on falsified data. Access creep in quality management is consistently underreviewed compared to finance and procurement.
8. Create maintenance work order + confirm completion
Plant maintenance fraud typically involves recording work that did not occur — charging labor, spare parts, or contractor services for activity that was never performed. A user who can both open and confirm a maintenance work order controls both sides of this transaction. This conflict is frequently absent from enterprise reviews that focus on finance.
9. Maintain employee bank account + execute payroll run
SAP payroll SoD risk is among the most direct fraud paths in any manufacturing SAP environment. A user who can change payroll bank details and trigger the payroll run can redirect salary payments to an account they control. HR and payroll functions are often reviewed separately from financial controls, so neither team sees the combined risk.
10. Create user account + assign roles
SAP Basis SoD violations represent a master-key conflict. A user who can both create SAP accounts and assign roles can create a ghost account, assign it any combination of access, and use it to exploit other conflicts on this list — without any independent oversight of the original account creation. Basis administration is frequently excluded from business-side access reviews on the grounds that it is a technical function. It is not.
For a full picture of how these conflicts fit into the broader manufacturing identity governance model — and the evidence gap they create — the white paper The Audit Was Never Just SAP is the right starting point.
What is the right response to a high-risk SAP SoD conflict?
The right response is to prevent the conflict at the point of access request, detect and remediate the violations that already exist, and retain evidence of every decision along the way.
Finding an SAP Segregation of Duties violation is step one. It is not the finish line.
The operating goal is prevention: validating access requests at the approval stage, before access is assigned. When a request would create a toxic combination, it is flagged and either blocked or routed for explicit risk acceptance before it goes live. This preventive model is the right response to dangerous SAP role combinations in a well-governed environment.
For violations that already exist — through access creep, role accumulation, or acquired environments — the response is detect, assess, and remediate. A well-defined SAP SoD rule set gives manufacturing teams a consistent starting point: detect the full scope of conflicting access across all affected users, assess severity and business context, and remediate through role splitting where possible, or through a documented compensating control where role splitting is not practical.
What auditors require — and what spreadsheet-based reviews consistently fail to produce — is evidence: a record showing the SAP SoD conflict was identified, a responsible reviewer examined it, a decision was made, and either the access was removed or a compensating control was documented and accepted.
Do SAP access risks exist outside the SAP environment too?
Yes — the same users hold access in Active Directory, Entra ID, ServiceNow, HR, and plant systems, and any compensating control that depends on those systems is only as strong as the governance over them.
Yes — and this is where many manufacturing companies have a significant governance gap.
The conflicts above are defined in SAP terms. But the users who hold them also have accounts in Active Directory, Microsoft Entra ID, ServiceNow, HR systems, and plant applications. Compensating controls for SAP SoD conflicts often depend on these non-SAP systems — and if those systems are not governed with the same rigor as the SAP environment, the compensating control is weaker than it appears.
Auditors are increasingly testing access risk across systems, not just within SAP itself. A manufacturer with strong controls inside SAP and weak governance over the surrounding systems still has an access evidence problem. Enterprise-wide identity governance — covering the SAP environment and the systems around it from a single governance model — is how manufacturing companies close this gap.
For the full picture of what that looks like in practice, the white paper The Audit Was Never Just SAP covers the evidence gap argument, the governance model, and a practical starting framework.
OpenIAM's manufacturing identity governance solution shows how unified governance addresses SAP access risk across the enterprise.
Frequently asked questions
What is the most dangerous SAP SoD conflict in manufacturing?
The vendor master and payment run combination is the most financially material SAP SoD conflict in manufacturing. A user who can create a vendor record and execute a payment run can introduce a fictitious supplier and release funds without any independent review. The SAP vendor master payment conflict requires no technical exploitation — the access itself is the vulnerability.
What SAP modules carry the highest SAP access risk in manufacturing?
The highest SAP access risks in manufacturing sit in Finance and Controlling (FI/CO), Materials Management (MM), HR and Payroll (HCM), and Basis. FI and MM generate the largest volume of cross-functional SAP SoD conflicts in manufacturing environments. Basis carries the master-key risk: SAP Basis SoD violations allow users to create accounts and assign roles, amplifying conflicts across every other module.
How do you remediate an SAP Segregation of Duties violation?
The preferred remediation for an SAP Segregation of Duties violation is a role split — restructuring roles so no single user holds both conflicting functions. Where a role split is not feasible, a compensating control should be documented with rationale. In both cases the remediation decision must be retained as audit evidence showing who decided, what was done, and when.
Can SAP GRC detect all manufacturing SAP access risks?
SAP GRC detects access risk within the SAP environment effectively. It does not govern Active Directory, Microsoft Entra ID, ServiceNow, Salesforce, HR systems, or plant applications. The full scope of SAP access risk in manufacturing extends beyond any SAP-native tool — a broader governance layer is needed to connect SAP access decisions to the complete identity picture.
What evidence does an auditor need after an SAP SoD conflict is found?
An auditor reviewing an SAP Segregation of Duties violation needs the full chain: the access that created the conflict, when it was identified, who assessed it, the decision made, the action taken, and a timestamp for each step. A completed spreadsheet does not satisfy this unless tied to a governed workflow with documented approvals and an exportable audit trail.
What is the difference between preventive and detective SAP access controls?
A preventive control validates requests before access is assigned — if a request would create a dangerous SAP role combination, it is flagged or blocked upfront. A detective control identifies SAP Segregation of Duties violations in access that already exists, through periodic scans or reviews. Preventive is the operating goal; detective remains necessary for legacy access and environments where preventive controls are being introduced incrementally.