Every one of these conflicts is detectable on day one. Most manufacturing companies have at least two of them. Your auditor is checking for all five.
If you run SAP in a manufacturing environment and you have not done a formal SoD review recently, there is a high probability that at least one of the conflicts in this post exists in your system right now. Not because your team made a mistake. Because SAP's role-based access model is designed to give people what they need to do their jobs — and over time, through promotions, temporary access grants, project roles, and emergency access that never gets revoked, users accumulate role combinations that individually look fine but together create dangerous conflicts.
Your auditor knows this. SOX ITGC testing, internal controls assessments, and COBIT access control reviews all include a specific set of role conflict checks in SAP. Whether your auditor is working to SOX, IFRS-aligned internal controls frameworks, or COBIT 2019, the testing approach for SAP SoD is consistent — because the underlying fraud risks are the same regardless of jurisdiction. Finding these conflicts during an audit means a reportable deficiency, a management response, and potential re-testing the following year. Finding them before the audit means a remediation ticket.
The requirement is consistent: no single individual should be able to execute a complete financial transaction without independent oversight — the core principle of segregation of duties in SAP.
The five conflicts below are ordered by financial exposure. Each one is drawn from OpenIAM's manufacturing SoD rule set — purpose-built for manufacturing environments across nine SAP module groups. For each conflict we have included the specific transaction codes involved, what the conflict actually enables in plain language, and what it takes to fix it.
SAP does not natively prevent SoD violations. It assigns access based on job function. The rest is governance.
Why SAP does not prevent these conflicts
This is the question most IT Audit Managers hear from their CFO at least once: 'We spent millions on SAP. Why doesn't it stop this?' The answer is that SAP is an ERP system, not a governance system. SAP assigns access based on roles — roles that are defined by what a person needs to do their job. The purchasing manager needs to create purchase orders. The accounts payable manager needs to post invoices. The payroll administrator needs to run the payroll. Those are legitimate access grants.
The problem is accumulation. The purchasing manager who temporarily covered for a colleague during a system migration still has payment run access. The payroll administrator who was promoted to payroll manager three years ago still has the individual transaction access from their old role on top of their new management role. The finance director who needed emergency GL posting access during the year-end close never had it revoked.
None of these access grants were wrong at the time they were made. All of them create SoD conflicts today. And SAP has no built-in mechanism that says 'this user now holds a dangerous combination of roles.' That detection requires a separate governance layer — which is precisely what SoD rule sets in an IGA platform provide.
The five conflicts below are the ones your auditor will test first. They are also the ones that, left undetected, create the highest financial exposure.
T-codes: FK01 / FK02 + F110 / F-53
Auth objects: F_LFA1_BUK F_LFA1_GRP F_BKPF_BUK
This is the foundational procure-to-pay SoD conflict. It is the most frequently cited SAP access control finding in SOX and internal controls audits, and the most financially damaging when exploited. No audit of a SAP environment skips this check.
The reason it is so dangerous is structural: the same person who can introduce a new supplier into the system can also be the person who approves payment to that supplier. Every other financial control -- purchase order approval, goods receipt, invoice matching -- can be bypassed if the payment run itself is controlled by the person who created the payee.
What actually happens
An accounts payable administrator who holds both FK01 and F110 access can create a vendor record with their own bank account details, or a related party's account, as the payment destination. They then run the automatic payment program, which processes outstanding invoices including the ones they have just created against their fictitious supplier. The payment leaves the company's banking system before anyone else has reviewed it. This pattern has been detected in manufacturing companies of all sizes globally. It typically runs for months before discovery because the transactions individually look normal -- a supplier was paid. The fraud is in who created the supplier and who authorized the payment being the same person.
How to fix it
Split roles: remove F110 and F-53 access from any user who holds FK01 or FK02. Where the same small team must cover both functions, implement mandatory dual approval on all payment runs -- two different named individuals must review and sign off before the payment medium is created -- with documented evidence retained as audit proof.
T-codes: FI12 + F-53 / FBZP
Auth objects: F_BVTYP F_BKPF_BUK
Bank redirection fraud is the highest-value-per-incident fraud pattern in corporate financial systems. It does not require access to many transactions, sophisticated manipulation of records, or extended periods of operation. A single bank account change before a large payment run can redirect a material sum in one transaction.
The pattern is well documented in forensic accounting literature and increasingly targeted by external threat actors who combine social engineering with insider access to execute it. The control that prevents it is simple: the person who can change where money goes cannot also be the person who sends it.
What actually happens
A treasury or finance administrator who can modify the company's house bank account records in FI12 and also execute payment runs can change the beneficiary account for vendor payments -- or the company's own outgoing payment accounts -- and immediately process a payment to the modified destination before the change is detected. In a manufacturing environment processing significant supplier payment volumes, a single altered bank record before a weekly or monthly payment run can redirect a material amount to an external account. Unlike the vendor master conflict above, this one does not even require creating a fictitious supplier. It simply redirects an existing, legitimate payment to a different account. The original supplier never receives their payment. Recovery is typically very difficult once the funds have cleared.
How to fix it
Split roles: FI12 access must be restricted to treasury or finance administration staff who have no payment execution access whatsoever. Compensating control: every change to a house bank account record triggers an automated alert to the CFO and finance controller immediately -- before any subsequent payment run. A manual countersignature requirement on all bank master data changes, with the signature retained as audit evidence, is the minimum standard.
T-codes: ME21N / ME22N + ME28 / ME29N
Auth objects: M_BEST_BSA M_BEST_WFB
Purchase order self-approval is the most common SoD conflict in mid-market manufacturing companies, precisely because it feels administratively necessary. A buyer who can raise an order but has to wait for someone else to release it before it can be confirmed to the supplier feels like a bottleneck in a fast-moving procurement environment. The solution -- give the buyer release authority for their own orders -- is the conflict.
The release step in SAP procurement exists specifically as an independent authorization that confirms the purchase is necessary, appropriately scoped, and within budget before the company commits to spend. Self-release removes that check entirely. In a manufacturing environment processing hundreds of purchase orders per week, even a small systematic inflation of order values is very difficult to detect without independent release authority.
What actually happens
A buyer who holds ME21N and ME28 access can raise purchase orders for any amount from any supplier and release them without a second person confirming the purchase is necessary or appropriately priced. In practice this conflict enables three overlapping risks: directing spend to a related-party supplier at inflated prices; creating purchase orders for goods or services that are never delivered but whose invoices are subsequently approved; and circumventing the budget control that the release hierarchy is designed to enforce.
How to fix it
Implement a formal release hierarchy where the purchase order creator cannot be an authorized release approver for their own orders. OpenIAM enforces this at provisioning -- the system prevents the role combination from being assigned. Where small team sizes make full separation difficult, the minimum compensating control is a supervisor countersignature for all purchase orders above a defined value threshold.
T-codes: FB50 / FB01 / FBS1 + FB08
Auth objects: F_BKPF_BUK F_BKPF_KOA
External auditors publish annual inspection reports identifying the most common audit deficiencies. Self-approved journal entries appear in virtually every cycle. This is not because auditors have recently discovered the risk -- it is because the control is structurally difficult to enforce in SAP environments where the same finance team member who prepares entries also has approval authority, particularly at month-end when speed matters and approval workflows feel like friction.
The financial statement integrity risk here is direct and material. Journal entries in SAP can adjust any GL account balance -- revenue, expenses, provisions, liabilities, intercompany balances. A person who can post and approve their own entries can manipulate any of these balances without a second pair of eyes ever reviewing the entry.
What actually happens
A finance team member who holds FB50 and FB08 access without a separate approval requirement can post journal entries adjusting revenue upward, expenses downward, provisions below the level required by accounting standards, or intercompany balances in ways that benefit particular entities in a group structure. They can also reverse entries made by colleagues, substituting different amounts or account assignments. The manipulation is visible in the accounting records -- but only to someone who reviews every manual journal entry independently, which most organizations do not do without an automated control forcing it.
How to fix it
Implement a formal journal entry approval workflow in SAP where every manual entry requires a named approver who is different from the preparer. This must be a system configuration requirement, not just a policy statement -- the workflow must technically prevent the preparer from approving their own entries. Compensating control where workflow is not yet implemented: monthly independent review by a finance controller of all manually posted entries above a defined materiality threshold, with documented sign-off.
T-codes: CS02 + CO02 / CO01
Auth objects: C_STUE_BER C_AFKO_AWK
This is the manufacturing-specific conflict that distinguishes this post from a generic SAP SoD list. Every FI and MM conflict above applies to any SAP-using organization. This one applies specifically to companies with production operations, and it carries two distinct risk dimensions that the others do not.
The financial risk is the same structural pattern as the conflicts above: a person who controls the definition of what should happen in production and also authorizes production to begin can manipulate costs without independent review. The quality and compliance risk is specific to manufacturing: in environments with OEM service certifications, ISO quality certifications, or safety-regulated production, the bill of materials is not just a cost document -- it is the technical specification that production must conform to.
What actually happens
A production planner or workshop manager who can modify bill of materials records and release production orders against those modified BOMs can substitute cheaper or unauthorized components in the production specification and immediately authorize production based on that altered specification. The financial impact accumulates across every production order that runs against the modified BOM. In a cost-plus contracting environment -- common in contract manufacturing, defence, and heavy equipment -- inflated BOM costs flow directly into customer invoices. The quality and compliance risk is the more acute concern in OEM-accredited service environments: an unauthorized component substitution identified during a warranty claim or OEM audit can result in certification withdrawal, insurance voiding, and direct product liability exposure.
How to fix it
Split roles: BOM maintenance must be restricted to engineering or technical operations with no production order release access. All BOM changes must trigger an approval workflow requiring sign-off from the technical authority before the change is effective. In OEM-accredited environments, BOM changes affecting certified maintenance specifications must additionally be reviewed by the quality and compliance function. Production order release must be held by a separate production planning role that receives approved BOMs from engineering and cannot modify them.
What to do if you recognize these conflicts
If any of the five conflicts above sounds familiar — if you know or suspect that someone in your organization holds both sides of one of these role combinations — the right first step is a structured SoD scan, not an immediate access revocation. Revoking access before you understand the scope of the conflict creates operational disruption and does not produce the audit evidence you will need to show your remediation was systematic and complete.
A structured approach has three steps. First, detect: run a formal SoD scan against your live SAP environment to identify every instance of every conflict. Second, assess: for each violation, determine whether a role split is operationally feasible or whether a compensating control is needed. Third, evidence: document every decision — remediations implemented, compensating controls in place, management sign-offs. The auditor is not just checking whether violations exist. They are checking whether you have a systematic, evidenced process for detecting and addressing them.
The five conflicts in this post are the starting point. A complete manufacturing SoD program covers nine SAP module groups — FI, MM, SD, PP, CO, QM, Basis, HR/Payroll, and Plant Maintenance. OpenIAM ships purpose-built rules for every module group, calibrated specifically for manufacturing environments, with a plain-language fraud scenario on every rule written for the non-technical stakeholders who will read your audit response.
The auditor is not just checking whether violations exist. They are checking whether you have a systematic, evidenced process for detecting and addressing them.
Go deeper on manufacturing SoD
The OpenIAM SoD Accelerator for Manufacturing ships purpose-built rules across nine SAP module groups.
Every rule includes the exact T-codes, authorization objects, control objective, and a plain-language fraud scenario written for CFOs and audit committees. Three resources to continue:
1. The complete manufacturing SoD rule set -- covering FI, MM, SD, PP, CO, QM, Basis, HR/Payroll, and Plant Maintenance: openiam.com/solutions/sap-compliance/sod-rules-manufacturing
2. Download the SAP SoD Risk Reference -- the full Core Edition rule matrix with control objectives, T-codes, and remediation guidance: openiam.com/resources/sap-sod-guide
3. To run a first scan against your SAP environment -- the first violation scan typically completes within hours of connecting: openiam.com/contact-sales
Frequently asked questions
Common questions about the five SAP SoD conflicts covered in this post.
What is MFG-FI-001 and why is it the most dangerous SAP SoD conflict?
⌄MFG-FI-001 is the Create vendor master + Execute payment run conflict -- rated Critical and the most frequently cited SAP access control finding in SOX and internal controls audits globally. A user who holds FK01 or FK02 (vendor master) access alongside F110 or F-53 (payment run) can create a fictitious supplier with their own bank account as the payment destination and approve payment to that supplier without any independent review. It is the most financially damaging SAP SoD conflict because it allows a single user to complete the entire fraud cycle -- create payee, approve payment -- without any other person being involved.
What is MFG-FI-006 and what makes bank redirection fraud so difficult to recover from?
⌄MFG-FI-006 is the Maintain bank master data + Initiate bank transfer conflict. It involves FI12 (bank account master) combined with F-53 or FBZP (payment execution). A user with both can modify the destination bank account for vendor payments and immediately process a payment to the modified account before the change is detected. Bank redirection fraud is particularly difficult to recover from because the payment clears the company's banking system before anyone else reviews the transaction. Unlike fictitious vendor fraud, it does not require creating a new supplier -- it simply redirects an existing legitimate payment. Recovery of funds after clearing is typically very difficult and often impossible.
What is MFG-MM-001 and why is purchase order self-approval so common in manufacturing?
⌄MFG-MM-001 is the Create purchase order + Approve purchase order conflict. It involves ME21N or ME22N (create or change PO) combined with ME28 or ME29N (release PO). It is the most common SoD conflict in mid-market manufacturing companies because it frequently arises from an operational workaround -- buyers are given release authority for their own orders to avoid procurement bottlenecks. The release step in SAP procurement exists as an independent control that confirms the purchase is necessary and within budget. Self-release removes that check entirely. In a manufacturing environment processing hundreds of purchase orders per week, even a small systematic inflation of order values is very difficult to detect without independent release authority.
What is MFG-FI-003 and why do self-approved journal entries appear in so many audit findings?
⌄MFG-FI-003 is the Post journal entry + Approve journal entry conflict. It involves FB50, FB01, or FBS1 (post GL document) combined with FB08 (reverse document), with authorization objects F_BKPF_BUK and F_BKPF_KOA. Self-approved journal entries appear in virtually every external auditor annual inspection report because the control is structurally difficult to enforce in SAP environments where the same finance team member who prepares entries also has approval authority -- particularly at month-end when approval workflows create friction. The risk is direct and material: a user who can post and approve their own entries can adjust any GL account balance -- revenue, expenses, provisions, intercompany balances -- without independent review.
What is MFG-PP-001 and why does it carry both financial and compliance risk?
⌄MFG-PP-001 is the Modify bill of materials + Release production order conflict. It involves CS02 (change BOM) combined with CO02 or CO01 (change or create production order with release), with authorization objects C_STUE_BER and C_AFKO_AWK. It is the manufacturing-specific conflict in this list -- the only one that applies specifically to companies with production operations. It carries two distinct risk dimensions: the financial risk of cost manipulation (a modified BOM with inflated component costs flows into production cost accounting and, in cost-plus contracting environments, into customer invoices) and the quality and compliance risk specific to OEM-certified or safety-regulated environments, where unauthorized component substitution can result in certification withdrawal, insurance voiding, and direct product liability exposure.