Run a vendor’s default segregation of duties ruleset against a mid-sized ERP and it will report several thousand conflicts. Hand that report to management and two things happen: nothing, and then a request to buy the vendor’s remediation module. The number is not wrong, exactly. It is the count of users who technically hold two authorizations that the ruleset considers incompatible, most of which are display access, organizational units the user never touches, roles assigned years ago and never used, or conflicts that exist on paper for a company of two hundred people who all know each other. Somewhere inside the thousands are the thirty or so that matter: the accounts payable clerk who can create a vendor and pay it, the depot manager who can enter an override and approve it, the developer who can post journals. Finding those thirty, proving they matter with usage and money, and getting them fixed is the job, and it can be done on any platform with a spreadsheet and a method.
This guide was rewritten in September 2026 and expanded from the original August 2026 version to add the full conflict matrix by cycle, the platform mapping for SAP, Oracle, Dynamics, NetSuite and Workday, the extraction pitfalls that make most analyses wrong before they start, the noise-reduction method, usage and exposure quantification, the remediation and mitigation options, the governance that keeps the ruleset alive, and a worked run at MidState Beverage, where a 550-hour ERP access engagement turned 2,160 raw hits into 23 users who had actually exercised both sides of a conflict. It is the technical companion to the universal SoD framework, which explains the four incompatible functions and how to reason about conflicts in any process; this one is about doing the analysis in a system.
In this guide
- Why role-level analysis misses the conflicts that matter
- Step 1: build the conflict matrix from business risk, not from the vendor
- Step 2: map each function to the technical objects on your platform
- Step 3: extract effective access, and the pitfalls that make it wrong
- Step 4: run the analysis and kill the noise
- Step 5: prioritize by usage and exposure
- Cross-system conflicts: the ones the ERP cannot see
- Step 6: remediate, mitigate or accept, and document which
- Step 7: keep it clean: provisioning checks, re-runs and ruleset governance
- Worked example: MidState Beverage runs the analysis on its ERP
- Common mistakes
Why role-level analysis misses the conflicts that matter
A segregation of duties conflict is a property of a person, not of a role: one identity holding the capability to perform two functions that should require two people. The distinction sounds academic and decides everything about the method. Roles are bundles of permissions, and in every real ERP a user holds several roles, each of which was designed to be clean on its own. The vendor-create role has no payment capability; the payment role has no vendor-create capability; the clerk who holds both has the conflict, and an analysis that checks roles one at a time will never see it. The same is true one layer down. A role called “AP Clerk” may contain, through a composite role, a copied role, a menu inheritance or a wildcard authorization value, capabilities that its name does not suggest, so the analysis has to resolve each user’s access to the level of the technical objects that actually grant the capability, the authorization objects and values in SAP, the functions and data-security policies in Oracle, the privileges beneath duties in Dynamics, and evaluate the union across everything the user holds.
Four other things escape a naive analysis. Direct assignments and profiles outside the role structure, of which the SAP_ALL profile is the notorious example, grant everything and appear in no role report. Generic and service accounts, shared by several people or used by interfaces, hold conflicts that no individual owns. Emergency or firefighter access grants temporary elevated capability whose use must be reviewed rather than analyzed statically. And the same person may hold different identities across the ERP, the banking portal and the payroll system, so that a conflict spans systems: the person who maintains vendor bank details in the ERP and releases payments in the bank portal has a cross-system conflict that a single-system analysis will report as clean. The method below handles each of these explicitly because each has been the finding that the vendor tool missed.
Step 1: build the conflict matrix from business risk, not from the vendor
The conflict matrix is the list of function pairs the organization considers incompatible, each with the risk it addresses and a rating. Vendor rulesets are a useful reference and a poor starting point: they are written for every customer at once, they rate everything high, and they contain hundreds of pairs that reflect a large public company’s control environment rather than yours. Build the matrix from the organization’s own processes and risks, using the four incompatible functions, authorization, custody, recording and reconciliation, as the test for each pair, and using the risk and control matrix to identify which pairs correspond to real fraud or error risks in your processes. Thirty to fifty pairs is typical for a mid-sized organization; more than a hundred means the matrix is duplicating the vendor list. The table gives the pairs that appear in nearly every matrix with the risk each addresses; the rating column is illustrative and should be set from the organization’s own exposure.
| Cycle | Function A | Function B | Risk if one person holds both | Typical rating |
|---|---|---|---|---|
| Purchase to pay | Create or change vendor master (including bank details) | Enter or approve invoices, or run payments | Fictitious vendor or diverted bank account paid without a second person | High |
| Purchase to pay | Enter supplier invoice | Approve supplier invoice or release payment block | Invoice for goods not received, or inflated, paid on one authority | High |
| Purchase to pay | Create purchase order | Post goods receipt | Receipt confirmed for goods never delivered, completing a three-way match fraudulently | High |
| Purchase to pay | Run payment program | Maintain bank account master or payment method configuration | Payments redirected | High |
| Order to cash | Create or change customer master and credit limit | Enter sales orders or release credit holds | Sales to uncreditworthy or related parties; bad debt | Medium |
| Order to cash | Issue credit memos | Apply cash or write off receivables | Cash theft concealed by credits and write-offs | High |
| Order to cash | Maintain pricing and discount conditions | Enter sales orders | Unauthorized discounts to favored customers | Medium |
| Record to report | Post journal entries | Approve journal entries above threshold | Manipulated results; concealed errors | High |
| Record to report | Open or close posting periods | Post journal entries | Back-dated entries after close | Medium |
| Record to report | Maintain chart of accounts or account determination | Post journal entries or run closing programs | Misclassification by design | Medium |
| Payroll | Maintain employee master and pay rates | Run payroll or approve payroll output | Ghost employees; unauthorized rate changes paid | High |
| Payroll | Maintain employee bank details | Release payroll bank file | Diverted net pay | High |
| Inventory | Post inventory adjustments or scrap | Perform or approve physical counts | Theft concealed by adjustments | Medium |
| Route and settlement (distribution) | Enter settlement overrides | Approve settlement overrides | Cash shortages written off by the person responsible for them | High |
| IT | Develop or change programs and configuration | Deploy to production, or execute business transactions in production | Logic altered and exploited without detection | High |
| IT and security | Administer users and roles | Execute any financial transaction | Self-granted access; audit trail undermined | High |
Every pair in the matrix has an owner, usually the process owner, who agreed that the pair is a conflict, agreed the rating, and will own the remediation decisions for it. A matrix without owners produces an analysis without consequences. The matrix also has a version and a change record, because it will be edited as remediation proceeds and as the argument about particular pairs plays out, and an analysis is only reproducible against a stated matrix version.
Step 2: map each function to the technical objects on your platform
A business function like “create vendor master” has to be translated into the technical capability that grants it on the platform in question, and the translation is where the analysis becomes platform-specific. The translation is done once per function, validated with the security administrator and the process owner, and stored with the matrix; it is the part of the work that a vendor ruleset supplies out of the box and the part most worth checking, because a vendor mapping that omits a custom transaction or an alternative route to the same capability produces a clean result for a user who is not clean. The table gives, for the platforms most internal auditors meet, where the capability is defined and the level at which the analysis has to be performed. The transaction codes and object names cited for SAP are the standard ones; every organization has custom transactions that must be added.
| Platform | How capability is granted | Level the analysis must reach | Illustrative mapping for “create vendor” and “run payments” | Platform-specific traps |
|---|---|---|---|---|
| SAP ECC and S/4HANA | Roles (PFCG) containing transaction codes and authorization objects with field values; composite roles; profiles; direct profile assignment | Authorization object and field value (for example activity 01 create versus 03 display; company code; document type), not transaction code alone | Vendor: XK01/FK01 or the S/4 business partner app with the vendor account objects at create activity. Payments: F110 with the payment program authorization for the company code | SAP_ALL and SAP_NEW profiles; wildcard values; Fiori apps reaching the same capability through different transactions; reference users |
| Oracle E-Business Suite | Responsibilities containing menus of functions; data access through organization and ledger security | Function and organization or ledger scope | Vendor: supplier entry functions in the payables responsibility. Payments: payment process request and payment batch functions | Functions reachable through multiple menus; form personalizations; generic responsibilities like “All Payables” |
| Oracle Fusion Cloud ERP | Job roles and duty roles composed of privileges; data security policies | Privilege and data scope (business unit, ledger) | Vendor: supplier creation privileges. Payments: payment submission and approval privileges | Seeded job roles far broader than their names; data roles granting cross-unit access |
| Microsoft Dynamics 365 Finance and Operations | Security roles composed of duties composed of privileges; legal entity scope | Privilege, with the maintain versus view distinction, and legal entity | Vendor: vendor master maintenance privileges. Payments: payment journal posting and vendor payment privileges | Standard roles such as “Accounts payable manager” containing both sides; role customization drift |
| NetSuite | Roles with permission levels (view, create, edit, full) per record and transaction type; subsidiary restrictions | Permission level per record type | Vendor: vendor record at create or full. Payments: bill payment at create plus payment approval | Administrator and full-access roles; global permissions; custom roles copied from administrator |
| Workday | Security groups granting domain permissions and business process step authority | Domain permission (view versus modify) and business process step (initiate, approve) | Supplier: supplier data domains at modify. Settlement: settlement run and payment release business process steps | Unconstrained security groups; business process definitions allowing initiator approval |
| Any platform, cross-system | Separate identities in the ERP, bank portal, payroll and expense systems | The person, matched across systems by employee identifier | Vendor bank details in ERP versus payment release in the bank portal | No common identifier; contractors and shared logins |
Step 3: extract effective access, and the pitfalls that make it wrong
Effective access is the complete set of capabilities each user actually holds on the analysis date: every role and composite role, every profile, every direct assignment, resolved to the technical objects, with the organizational scope attached, for every active identity including generic, service and emergency accounts. It is extracted from the system’s own tables or its security reporting, never from a spreadsheet the security team maintains, and the extract is treated as information produced by the entity: the query is documented, the auditor re-performs or observes it, and the counts are reconciled. The IPE method applies in full. The table lists the extraction sources and the pitfalls that recur.
| Element | Where it comes from (SAP example; equivalents exist elsewhere) | Pitfall |
|---|---|---|
| User list with status and last logon | User master (USR02): lock status, validity dates, last logon, user type | Including locked or expired users inflates results; excluding dialog-only misses service accounts that post transactions |
| User-to-role assignments | Role assignment table (AGR_USERS) with validity dates; composite role resolution (AGR_AGRS) | Expired assignments still listed; composite roles not expanded |
| Role-to-capability resolution | Authorization data per role (AGR_1251) and transaction assignments (AGR_TCODES); the user information system (SUIM) for validation | Menu transactions without the underlying objects; objects with wildcard or range values |
| Profiles and direct assignments | User profile assignments (UST04 and related); SAP_ALL and SAP_NEW holders | Profiles outside roles never appear in a role-based report |
| Change history | User and authorization change documents (USH02 and related; SUIM change documents) | Access granted and removed between extractions is invisible to a point-in-time analysis |
| Emergency access | Firefighter or emergency ID logs from the GRC tool or a manual register | Static analysis excludes it; the log review is a separate control |
| Cross-system identity | HR employee identifier mapped to each system’s user identifier | No mapping means cross-system conflicts cannot be found |
Three practical decisions belong in the workpaper before the analysis runs. The analysis date, and the fact that the extract is a point in time; where the period matters, the change history is examined separately. The treatment of locked, expired and never-logged-in users, which is normally to exclude them from the conflict count but list them separately, since a dormant account with a conflict is an access review finding rather than an SoD finding. And the treatment of generic and service accounts, which is to include them, attribute them to the people or interfaces that use them, and report their conflicts under the owner’s name, because a shared “APADMIN” account with both sides of every conflict is the most common way a small finance team defeats its own role design.
Step 4: run the analysis and kill the noise
The analysis itself is a join: for each user, for each pair in the matrix, does the user’s effective access include a capability mapped to function A and one mapped to function B, with overlapping organizational scope? On a small system it runs in a spreadsheet or a database query; on a large one it runs in a GRC or identity governance tool, and the tool’s value is the join at scale plus the mapping library, not any judgment about what matters. The raw output is large because the join is honest. The noise-reduction sequence turns it into a list of real conflicts, and each step is recorded with the count before and after so that the reduction can be defended.
| Step | What is removed | Why it is not a conflict | What to keep visible |
|---|---|---|---|
| 1 Activity level | Hits where one side is display-only (for example SAP activity 03, view permission in NetSuite) | Viewing a vendor and paying it is not a conflict | Mapping validated so that “display” really is display |
| 2 Organizational scope | Hits where the two capabilities apply to different company codes, plants, legal entities or business units with no overlap | Creating vendors in entity A and paying in entity B cannot complete a fraud in either | Cross-entity intercompany exposure where it exists |
| 3 User status | Locked, expired, never logged in | Capability that cannot be exercised | Reported separately as access hygiene findings |
| 4 Technical accounts | Interface and batch accounts that cannot log on interactively | No person behind them | Confirm they really cannot be used interactively; report those that can |
| 5 Approved mitigations | Hits already covered by a documented, tested mitigating control or an approved risk acceptance | The residual risk has been addressed | The mitigation evidence; expired acceptances come back in |
| 6 Usage (step 5 below) | Nothing removed; hits are ranked by whether both sides were exercised | Capability that was never used is lower priority, not absent | The full list; prioritization is not deletion |
A reduction from several thousand hits to a few hundred user-rule pairs and a few dozen users is normal. A reduction to zero is not, and usually means the mapping was wrong or the scope filter was too aggressive. The numbers at each step go into the report, because management’s first response to an SoD finding is that the tool over-reports, and the answer to that is the table showing exactly what was excluded and why.
Step 5: prioritize by usage and exposure
Capability is the conflict; usage is the evidence that the conflict is live; exposure is the reason anyone should act. For each remaining user-rule pair, the analysis asks whether the user actually executed both functions in the period, and, where they did, what the transactions were worth. Usage comes from the system’s own record of who did what: document headers carry the creating and approving user (accounting documents, invoices, purchase orders, vendor master change documents), and transaction statistics show which transactions a user executed. A user who holds both create-vendor and pay-vendor and did both in the same quarter is a different finding from one who holds both and has only ever run payments, and the report should say so.
Exposure is quantified in the currency the audit committee thinks in. For the invoice-entry-plus-approval pair, sum the invoices the user both entered and approved; for the vendor-plus-payment pair, sum the payments to vendors the user created or whose bank details the user changed; for the override pair, count and value the overrides the user both entered and approved. The quantification is also the population for any substantive testing the finding demands: if a user both created a vendor and paid it, someone should look at that vendor. The procure-to-pay fraud analytics catalog contains the cross-stage tests that do exactly this, and the accounts payable analytics guide covers the single-table ones. The table shows the shape of the output.
| User (role) | Conflict pair | Both sides exercised in period | Exposure | Priority |
|---|---|---|---|---|
| AP clerk, head office | Create vendor / enter and approve invoice | Yes: created 4 vendors, entered and approved 61 of their invoices | 287,400 dollars paid to those vendors | 1: investigate vendors, remove approval |
| Depot manager, three depots | Enter override / approve override | Yes: 1,412 self-approved overrides across eleven managers | Cash shortages written off; value in route cash report | 1: workflow redesign |
| Controller | Post journal / approve journal | Yes: 38 journals above threshold self-approved | 4.1 million dollars of entries | 2: mitigating review by CFO, then role split |
| Payroll specialist | Maintain employee bank details / release payroll file | No: bank file released by treasury in every cycle | None exercised; capability remains | 3: remove file release capability |
| ERP administrator | Maintain users and roles / post financial transactions | No transactions posted | None exercised | 3: remove transactional roles; monitor |
Cross-system conflicts: the ones the ERP cannot see
The ERP is no longer where every incompatible function lives. Payments are released in a bank portal, expenses approved in an expense platform, purchase requisitions raised in a procurement tool, employees and pay rates maintained in a human resources system, and cloud consoles grant administrators the ability to alter any of them. A person who maintains vendor bank details in the ERP and holds a release token for the bank portal has the highest-rated conflict in the matrix, and the ERP analysis reports them as clean because the second capability lives elsewhere. The method extends across systems in three moves. Build the identity map first: an employee identifier matched to each system’s user identifier, obtained from the HR system and each platform’s user list, with contractors and shared logins resolved to named people. Extend the matrix with the cross-system pairs that matter, which are few and obvious once listed: vendor master or bank details versus payment release; employee master or bank details versus payroll file release; purchase requisition approval versus receipt; expense submission versus expense approval; cloud or database administration versus any financial transaction. Then extract effective access from each platform at the level its permission model requires, join on the identity map, and run the same noise and usage sequence. The bank portal and payroll platform extracts are often the easiest to obtain and the most revealing, because their user lists are short and their release rights are exactly where the money leaves. The identity and access management guide covers the identity map as a program control; here it is simply the join key without which the analysis stops at the ERP boundary.
Step 6: remediate, mitigate or accept, and document which
Every real conflict ends in one of three states, and the report should show which and who decided. Remediation removes the conflict: one side of the capability is taken away, a role is split, a workflow is reconfigured so the requester cannot approve, or the task is reassigned. Mitigation leaves the capability in place and adds a control that would detect its misuse: an independent review of vendor master changes made by users who can also pay, a review of self-approved journals, a monthly report of overrides by requester and approver. Acceptance leaves the conflict in place with no mitigation because the exposure is judged tolerable, typically at a small site where the only alternative is to have no one able to do the work; it is recorded with the owner’s signature, an expiry date, and the exposure at the time. The order of preference is remediation, then mitigation, then acceptance, and the auditor’s role is to make sure each decision is explicit and that mitigations are tested rather than described. The preventive, detective and corrective controls guide is the reference for what makes a mitigating control real.
| Conflict | Remediation options | Mitigation if remediation is not possible | Acceptance conditions |
|---|---|---|---|
| Create vendor / pay vendor | Move vendor master maintenance to a master data role; require second-person approval of vendor bank changes in workflow | Weekly review of vendor master changes by a person without payment capability, evidenced; positive pay or bank-account validation service | Rarely acceptable; exposure too direct |
| Enter invoice / approve invoice | Approval workflow routed to budget holder; remove approval from AP roles | Sample review of invoices entered and approved by the same user, with a threshold above which none may be self-approved | Small sites with a documented monthly review by finance |
| Post journal / approve journal | Threshold-based approval workflow; remove approval from posting roles | Monthly review of self-approved journals by the CFO | Not acceptable for the controller of a reporting entity |
| Enter override / approve override | Reconfigure workflow to exclude the requester; route depot manager overrides to regional manager | Daily override report by requester and approver reviewed at region level | Never for cash-handling processes |
| Develop / deploy | Pipeline identity deploys; separate deployer role | Independent monthly review of every production deployment against tickets | Temporary, with an end date tied to tooling |
| Security administration / financial transactions | Remove transactional roles from administrators | Log review of administrator activity in transactional areas | Not acceptable |
Step 7: keep it clean: provisioning checks, re-runs and ruleset governance
An SoD analysis is a snapshot, and a clean snapshot decays as soon as the next access request is approved. Three controls keep it clean. A preventive check at provisioning, where every access request is tested against the matrix before approval and any conflict it would create is either refused, mitigated or accepted at the point of granting; this is the control that stops the problem being recreated, and it is what the GRC and identity governance tools are for. A periodic re-run, quarterly for the high-rated pairs, with the results reconciled to the previous run so that new conflicts are visible and resolved conflicts are confirmed. And governance of the matrix and the mapping: an owner, a version, a change process, an annual review with process owners, and a reconciliation to the platform’s transaction and object inventory so that custom transactions and new modules enter the mapping. The user access review is the natural place to surface the re-run results, since reviewers deciding whether to keep a user’s access should see the conflicts that access creates.
Tooling is a scale decision, not a control. Organizations with a few hundred users on one ERP can run the analysis in a database or a spreadsheet from the extracts above, and the discipline of building the mapping themselves is worth the effort. Organizations with thousands of users, several platforms or continuous provisioning need a tool for the provisioning check and the re-runs, and the market offers platform-native modules, cross-platform GRC suites and identity governance products that include SoD. Whichever is used, the auditor tests the tool’s mapping against the organization’s matrix, its extraction against the system, and its noise-reduction logic against the sequence above, because a tool configured with the vendor’s ruleset and left alone reports thousands of conflicts and gets ignored.
Worked example: MidState Beverage runs the analysis on its ERP
MidState Beverage, a three-state drinks distributor with twelve depots and a 2013 ERP route-accounting module, gave its six-person audit function an FY27 engagement on ERP user access of 550 hours plus 140 hours of a co-sourced ERP security specialist, placed by the IT audit plan after the ERP scored highest in the function’s first IT risk assessment. The segregation of duties analysis was one of three workstreams. The ERP had 412 active users across head office and the depots; the finance team had a vendor-supplied ruleset installed but had never acted on its output, which stood at 8,900 conflicts.
The team built its own matrix of 38 pairs with the controller, the operations director and the head of route accounting, each pair owned and rated. The co-sourced specialist mapped the 38 pairs to the ERP’s authorization objects and to the route-accounting module’s own permission tables, which the vendor ruleset did not cover at all, and added 14 custom transactions the ruleset had never heard of. Extraction from the user, role and authorization tables was performed by the ERP administrator with the specialist observing and re-counting; 412 active users, 31 locked or expired users listed separately, 9 generic accounts attributed to the depots that used them. The join produced 2,160 user-rule hits. The noise sequence removed 1,380 for display-only activity, 412 for non-overlapping depot scope, 94 for the locked users, and 60 for interface accounts, leaving 214 hits across 61 users. Usage analysis over nine months of document headers showed that 23 of the 61 had exercised both sides of at least one high-rated pair.
| Stage | Count | Note |
|---|---|---|
| Vendor ruleset output (untouched since installation) | 8,900 conflicts | Not used; cited to management as the reason nothing had happened |
| MidState matrix | 38 pairs, 16 rated High | Owned by controller, operations director, head of route accounting |
| Raw hits from the join | 2,160 user-rule pairs | 412 active users |
| After activity-level, scope, status and technical-account filters | 214 user-rule pairs, 61 users | Each filter count recorded |
| Users who exercised both sides of a High pair in the period | 23 | Usage from document headers and change documents |
| Exposure quantified | 1.9 million dollars of invoices entered and approved by the same user; 1,412 self-approved overrides; 38 self-approved journals | Populations handed to substantive testing |
| Disposition | 9 role changes; 6 workflow reconfigurations; 14 mitigating controls; 3 risk acceptances | Acceptances at the three smallest depots, signed by the COO, expiring at ERP migration |
Three results shaped the report. The override pair confirmed, from the access side, what the route cash engagement had found from the transaction side: eleven depot managers held both enter and approve, and the workflow’s routing rule was the cause, so the finding was written once and cross-referenced. The AP clerk who had created four vendors and approved sixty-one of their invoices became a substantive test: all four vendors were legitimate, the clerk had been covering for a colleague on leave, and the finding was a role-design one with the 287,400 dollars recorded as exposure rather than loss. And the 8,900-conflict ruleset was replaced by MidState’s matrix in the vendor tool, with a preventive provisioning check switched on and a quarterly re-run assigned to the controller, which the CAE reported to the audit committee as the change that would keep the engagement’s result from evaporating. The workstream used 190 of the engagement’s hours, 60 of them the specialist’s.
Common mistakes
- Analyzing roles instead of users. Conflicts live in the union of everything a person holds. Resolve access to the object level per user.
- Starting from the vendor ruleset. Build the matrix from your processes and risks, with owners, and use the vendor’s list only as a check for omissions.
- Stopping at transaction codes. Activity values and organizational scope decide whether a hit is real.
- Extracting from a spreadsheet. Effective access comes from the system’s tables, with the query documented and the counts reconciled.
- Forgetting profiles, generic accounts and firefighters. They hold the worst conflicts and appear in no role report.
- Ignoring cross-system conflicts. Vendor bank details in the ERP plus payment release in the bank portal is a conflict no single-system tool will find.
- Reporting raw counts. Show the reduction sequence with counts at each step, then usage, then exposure.
- Treating unused capability as no finding. Unexercised conflicts are lower priority, not absent; they are removed or accepted, not dropped.
- Accepting mitigations that are descriptions. A mitigating control is tested like any other control.
- Running once. Without a provisioning check and a quarterly re-run, the clean result lasts until the next access request.
Related guides
- Segregation of duties beyond the ERP: a universal framework
- How to perform a user access review
- How to audit identity and access management
- How to audit privileged access
- IPE: testing information produced by the entity
- The P2P fraud analytics catalog
- Accounts payable analytics
- Preventive, detective and corrective controls
- The risk and control matrix template
- Testing automated controls and system configurations
- Building the IT audit plan
- IT general controls: the complete primer
- RCM Workbench
Leave a Reply