SAP SoD conflicts: what auditors flag and how to fix them
SAP SoD conflicts auditors keep flagging, by process, with t-codes and fixes. Clear them without a full GRC project. Includes a 30-day plan.
SAP SoD conflicts (segregation of duties) recur in published audit reports, from a US school district's internal audit to city auditors in Canada. The common thread: one person's SAP access lets them complete two steps the business thought were split, such as creating a vendor and paying it.
The usual choice looks binary: live with a repeat finding, or fund a full SAP GRC Access Control implementation. For many manufacturers on a single SAP ECC or S/4HANA system, there is a middle path.
Below: how SoD conflicts arise in SAP, the pairs auditors flag, why they matter in India, how to fix them, and a 30-day plan.
What an SoD conflict means in SAP
An SoD conflict exists when a user's combined SAP authorisations let them perform two functions that should sit with different people. It is defined by what the system allows, not by job titles.
In SAP's Access Control model, an action is a transaction code, Fiori app or OData service. A permission is the set of authorisation objects it checks, as maintained in SU24. Rule sets group these into functions and pair functions into risks. SAP's own example is a user who can maintain vendor master data and also process vendor invoices and payment runs (SAP Learning).
The objects carry the organisational limits. F_BKPF_BUK controls accounting documents by company code, and F_REGU_BUK controls the automatic payment program, F110 (SAP Help). M_BEST_BSA covers purchase order document types, and M_EINK_FRG decides which release codes a user may use to approve purchasing documents (SAP Help; SAP Help).
Why role-level checks miss user-level conflicts
A user's access is the sum of all their roles, so two clean roles can create a conflict on the same user. SAP's remediation guidance calls out conflicts created when roles come together in a composite role, and says to rerun the analysis at user level once roles are clean (SAP Learning).
Organisational values decide whether a combination is real. SAP PRESS describes a user with FB60 (posting vendor invoices) for company code 1000 and FK02 (changing vendor master data) for company code 2000. That is a false positive, because the duties never meet (SAP PRESS). Grant both for one company code and the conflict is real, though neither role looks wrong.
Access also drifts. In 2012, Halifax's Auditor General found SAP roles assigned to individuals rather than positions, so staff who changed jobs could keep their old access (Halifax OAG). RSM's internal auditors noted in 2015 that such conflicts surface only when you analyse each user's full access profile (RSM).
SAP SoD conflicts that recur in audits
These pairs come up repeatedly in published audit reports and SoD rule sets. No study ranks them by frequency, so treat the table as a checklist. Transaction codes are typical ECC examples. SAP KBAs 2500245 and 2451928 cover the purchasing ones, SAP Help covers payroll, and the rest are sourced at the end. On S/4HANA, the rule set must also cover Fiori apps.
- Procure-to-Pay. Conflict: Change vendor master + post invoices or pay. Risk in plain words: Create a fake vendor or swap bank details, then pay. Typical SAP access: FK02 + FB60 or F110. Typical fix: Central vendor master team; dual control on bank fields
- Procure-to-Pay. Conflict: Create PO + release PO. Risk in plain words: Approve your own purchase. Typical SAP access: ME21N + release code in M_EINK_FRG. Typical fix: Release codes only for people who do not buy for that plant
- Procure-to-Pay. Conflict: Create PO + post goods receipt. Risk in plain words: Confirm a delivery that never arrived. Typical SAP access: ME21N + MIGO. Typical fix: Receipts by stores, restricted by plant
- Procure-to-Pay. Conflict: Post vendor invoice + run payments. Risk in plain words: Enter an invoice and pay it yourself. Typical SAP access: FB60 + F110. Typical fix: Payment run outside AP; independent proposal review
- Order-to-Cash. Conflict: Customer master + credit limits. Risk in plain words: Raise a limit to keep shipping to a risky customer. Typical SAP access: FD02 (F_KNA1_APP) + FD32 (F_KNKA_KKB); on S/4HANA, BP + UKM_BP. Typical fix: Credit limits with finance, not sales
- Order-to-Cash. Conflict: Billing or customer master + incoming payments. Risk in plain words: Divert a collection and hide it with a credit. Typical SAP access: Customer master and customer posting access. Typical fix: Cash application separate from billing
- Record-to-Report. Conflict: Post journals + approve them (park and post). Risk in plain words: Book an entry nobody reviews. Typical SAP access: Park and post rights for the same document types. Typical fix: Separate park and post; restrict document types (F_BKPF_BLA)
- Record-to-Report. Conflict: G/L master + posting. Risk in plain words: Open an account and move money through it. Typical SAP access: F_SKA1_BUK + F_BKPF_BUK. Typical fix: G/L master with a controller who does not post
- Inventory. Conflict: Goods movements + inventory differences. Risk in plain words: Remove stock, then adjust the count. Typical SAP access: MIGO + physical inventory posting. Typical fix: Independent count team; finance reviews differences
- HR and payroll. Conflict: Pay data + payroll run. Risk in plain words: Inflate pay or add a ghost employee. Typical SAP access: PA30 + PC00_M40_CALC (India payroll run) or PA03 (payroll control record). Typical fix: HR master data separate from payroll
- Basis/IT. Conflict: User administration + business transactions. Risk in plain words: Grant yourself access, then use it. Typical SAP access: SU01, PFCG + any posting. Typical fix: Administrators hold no business roles
- Basis/IT. Conflict: Develop + import to production; debug-change in production. Risk in plain words: Change programs or data outside change control. Typical SAP access: SE38/SE80 + STMS; S_DEVELOP, object type DEBUG, activity 2. Typical fix: No developer imports or debug-change in production, except logged emergency access
Public audit reports, dated here by year of finding, show the same pairs:
- Seattle Public Schools' internal auditors found in 2016 that purchasing and receiving were not separated in SAP, and that accounts payable staff could create vendors. Both were fixed by the 2020 follow-up (Seattle Public Schools).
- Ottawa's Auditor General found in 2015, and again in a 2019 follow-up, that vendor master changes, including bank details, could go live in SAP without approval (Ottawa OAG).
- San Diego's City Auditor found in 2011 that ERP support users had too much access to the financial system (San Diego). Kirklees Council's 2022-23 audit flagged a support user who could develop changes and import them to production (Kirklees Council).
Why SoD findings matter for Indian companies
SoD is part of internal financial controls, and statutory auditors report on those. Section 143(3)(i) of the Companies Act, 2013 requires the auditor to state whether the company has adequate internal financial controls with reference to financial statements, and whether they operate effectively.
Some smaller private companies are exempt from this report, but the fraud risk is the same, so the control still needs evidence.
CARO 2020 connects in two places. Clause 3(xi)(a) asks whether any fraud by or on the company was noticed or reported, with its nature and amount (BCAJ). Payments to a fictitious vendor are that kind of fraud. Clause 3(xiv) covers whether the company has an internal audit system commensurate with the size and nature of its business (DPNC), and a periodic SoD review belongs in that plan. For the wider ITGC picture, see our SAP ITGC and audit support.
How to fix SoD conflicts without a full GRC project
Most of the work is analysis, role design and routine, not software. SAP's own training sets the order: remediate first, and mitigate only what you cannot remediate (SAP Learning).
1. Adopt a rule set that fits your business
SAP describes its delivered rule set as a template covering Basis, Finance, HR and Payroll, Materials Management and more, to be reviewed and customised (SAP Learning). Drop risks for processes you do not run, and add custom Z transactions that post or change master data. Then add organisational rules for company codes and plants, and name a business owner for each risk.
2. Analyse at user level, not only role level
Role-level analysis shows which roles are conflicted by design. User-level analysis shows who can complete a risky process today. SAP Access Control offers both as separate reports (SAP user guide). Check authorisation values, not just transaction codes: SAP's knowledge base shows document-type and purchasing-organisation values combining on one user in ways a role designer may not intend (SAP KBA 2846590).
3. Remediate through role design
- Split composite roles that bundle conflicting functions.
- Use master and derived roles for plants and company codes. A derived role copies the master's authorisations with different organisational values (SAP Learning).
- Remove change access from display roles and drop unused transactions. SAP's training gives both as examples of issues that can be resolved quickly (SAP Learning).
- Use usage data carefully. ST03N shows transactions used and the users who call them (SAP Help), and STAD records transaction executions (SAP Learning). Check how much history your system keeps, make sure it covers month-end and year-end, and confirm removals with process owners.
4. Mitigate the conflicts you cannot remove
SAP's own example of an unavoidable conflict is a small office where one person covers two roles (SAP Learning). A small plant accounts team can be in the same position. A mitigating control needs an owner, a frequency and evidence. Examples:
- Vendor change review. Before each payment run, someone without vendor master access reviews Display Changes to Vendors (program RFKABL00, transaction S_ALR_87012089) (SAP KBA 2255805). SAP notes that its company code selection does not restrict the output, so expect other company codes in the list (SAP KBA 2406161).
- Dual control on bank fields. After a change to a field marked sensitive in Customizing, the vendor is blocked for the automatic payment run (F110). The block stays until a second authorised person confirms or rejects the change (SAP Help; SAP KBA 3018771). Confirmation runs through FK08/FK09 (the Confirm Supplier List app in S/4HANA Cloud). SAP documents the behaviour for Business Partner too (SAP KBA 3078397). Ottawa's auditor found a daily review of vendor changes was no substitute, since payments could go out before a change was checked.
- Inventory differences. Finance reviews differences above an agreed value before posting.
Record each mitigation with its risk, users, owner, frequency and end date, and re-test it.
5. Control emergency and privileged access
Give wide production access through a separate firefighter ID, used only against an approved ticket. In SAP Access Control, firefighter logs draw on STAD, change documents (CDHDR, CDPOS) and the SM20 security audit log, and a controller reviews each session (SAP Learning). Without GRC, use a locked emergency user, a ticket and a documented log review. Keep debugging with change rights (S_DEVELOP, activity 2) out of standard production roles.
6. Stop new conflicts at the request stage
Check every access request against the rule set before provisioning, and keep the result. Ottawa ran an SAP report on each request, but its auditor found the report had not been retained for two of three sampled requests. SAP Access Control builds this check into its request workflow.
7. Review access on a schedule
In a user access review, managers or role owners confirm that each user's access is still appropriate. Role content can be certified separately (SAP user guide). A separate SoD review asks risk owners whether each remaining conflict is still needed (SAP Learning). Remove what is not confirmed and keep the evidence.
When SAP GRC Access Control is the right answer
SAP Access Control is an add-on to SAP NetWeaver. It brings a predefined rule set, cross-system analysis, workflow-driven access requests with automated provisioning, role management, emergency access management and periodic certification (SAP user guide). It earns its cost when you have many SAP and non-SAP systems, heavy access request volumes that need workflow and automated provisioning, and a team to run it.
For a single production system with a small Basis team, a lighter approach is often enough. A scripted analysis of user, role and authorisation extracts can carry a one-off clean-up, but it is hard to keep current. A dedicated tool helps once you need repeatable reviews and pre-provisioning checks.
LogicMotive's AccessIntel is one such tool. It reads users, roles and authorisations, flags conflicts, simulates them before an access request is submitted, and runs reviews by company code and plant. LogicMotive sells no SAP licences, so the advice can follow your scale.
If S/4HANA is on your roadmap, build role redesign into the project, since Fiori apps become actions your rule set must cover. Our post on SAP ECC end of support in 2027 covers the timing.
A 30-day plan
For an illustrative mid-sized auto-components maker with three plants on one SAP system:
- Week 1, scope and data. Agree the company codes and plants in scope, the rule set baseline and risk owners. Extract users, roles and authorisations from production.
- Week 2, analyse. Run user-level and role-level analysis, remove false positives with organisational rules, and rank first the conflicts that can move money or stock.
- Week 3, quick wins. Remove leavers, old-position roles and confirmed unused transactions, strip change access from display roles, and switch on dual control for vendor bank fields.
- Week 4, mitigate and prevent. Write mitigating controls with owners and evidence, add an SoD check to access requests, and schedule the first access review.
Frequently asked questions
What is an SoD conflict in SAP?
It is a combination of SAP authorisations, across all of a user's roles, that lets one person perform two duties that should be split. An example is maintaining a vendor and paying it. Conflicts are defined by transactions, Fiori apps and authorisation objects, including company code and plant values.
Do we need SAP GRC Access Control to fix SoD conflicts?
Not always. The fix is mostly rule set design, user-level analysis, role redesign and documented mitigating controls. GRC Access Control suits companies with many systems and heavy access request volumes; a single-system company can often use a lighter tool or scripted analysis.
What makes a good mitigating control in SAP?
It targets a specific risk, has a named owner, runs at a set frequency and leaves evidence, such as a signed review of vendor changes before each payment run. SAP's guidance treats mitigation as the fallback for conflicts that role redesign cannot remove.
Does moving to S/4HANA remove SoD conflicts?
Not by itself. Conflicts come from how roles are designed and assigned, which a migration changes only if role redesign is in scope. S/4HANA also adds Fiori apps and OData services, which SAP treats as actions in a rule set.
Get an SoD risk snapshot
What you get. LogicMotive runs AccessIntel on a sample of your SAP roles and the users assigned to them. You receive a list of SoD conflicts grouped by business process, with a recommendation for each: fix through role redesign, or keep and mitigate with a named control.
What you provide. Extracts of users, role assignments and role authorisations from your production SAP system, or read access agreed with your IT team. Also the company codes and plants in scope, and a finance contact for process questions.
Contact us to scope your snapshot.
Sources
- Building a Rule Set, SAP Learning, learning.sap.com (accessed Oct 2026)
- Remediating Access Risks, SAP Learning, learning.sap.com (accessed Oct 2026)
- Mitigating Risks, SAP Learning, learning.sap.com (accessed Oct 2026)
- Monitoring the Emergency Access Session, SAP Learning, learning.sap.com (accessed Oct 2026)
- Performing User Access Review, SAP Learning, learning.sap.com (accessed Oct 2026)
- Defining Technical and Business Roles, SAP Learning, learning.sap.com (accessed Oct 2026)
- Executing a Payroll Run, SAP Help Portal, help.sap.com (accessed Oct 2026)
- User Guide, SAP Access Control 12.0 SP31 (January 2026), SAP SE, help.sap.com (accessed Oct 2026)
- Authorizations in Financial Accounting, SAP Help Portal, help.sap.com (accessed Oct 2026)
- Authorizations (SAP ERP Central Component Security Guide, Purchasing), SAP Help Portal, help.sap.com (accessed Oct 2026)
- M_EINK_FRG, SAP Help Portal, help.sap.com (accessed Oct 2026)
- Rights for Debugging, SAP Help Portal, help.sap.com (accessed Oct 2026)
- Define Sensitive Fields for Dual Control (Customers), SAP Help Portal, help.sap.com (accessed Oct 2026)
- Workload Monitor, SAP Help Portal, help.sap.com (accessed Oct 2026)
- SAP KBA 3018771, Sensitive Field for Customer/Vendor, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- SAP KBA 3078397, Behavior of sensitive fields in Business Partner, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- SAP KBA 2255805, Performance issues in Report RFKABL00 or RFDABL00, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- SAP KBA 2406161, S_ALR_87012089 does not validate company code as a selection parameter, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- SAP KBA 2500245, Authorization object M_BEST_BSA on transaction code, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- SAP KBA 2451928, Restrict MIGO usage based on the Purchase Order Document type, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- SAP KBA 2846590, Restrict PO/PR authorization objects based on other authorization object values, SAP Support, userapps.support.sap.com (accessed Oct 2026)
- Rulesets in SAP Access Control, SAP PRESS, blog.sap-press.com (accessed Oct 2026)
- Segregation of duty conflicts in ERP systems: Hidden vulnerabilities, RSM South Africa, rsm.global (accessed Oct 2026)
- Internal Audit Follow-Up Report: Segregation of Duties – Procurement (December 2020), Seattle Public Schools Office of Internal Audit, seattleschools.org (accessed Oct 2026)
- Follow-up to the 2015 Audit of Accounts Payable (May 2019), Office of the Auditor General, City of Ottawa, oagottawa.ca (accessed Oct 2026)
- SAP Authorizations – Review of Policies, Procedures and Processes (November 2012), Office of the Auditor General, Halifax Regional Municipality, hrmauditorgeneral.ca (accessed Oct 2026)
- ERP System Implementation Audit (Report 11-011), Audit Committee presentation, March 2011, Office of the City Auditor, City of San Diego, sandiego.gov (accessed Oct 2026)
- Audit Findings Report 2022-23 (committee agenda item 17), Kirklees Council, democracy.kirklees.gov.uk (accessed Oct 2026)
- The Companies Act, 2013 (section 143(3)(i)), India Code, indiacode.nic.in (accessed Oct 2026)
- CARO 2020 Series: New Clauses and Modifications – Frauds and Unrecorded Transactions, Bombay Chartered Accountants' Journal, bcajonline.org (accessed Oct 2026)
- The Companies (Auditor's Report) Order, 2020, Dewan P N Chopra & Co, dpncindia.com (accessed Oct 2026)
