⚖️ OasisPro · Segregation of Duties · PermissionWorks
Your access review passed.
Your auditor found
three conflicts.
IFS Cloud segregation of duties conflicts are the finding category that survives clean access reviews almost every time, because they don't live in any single permission. They live in the combination of two permissions, each individually fine, that become a real risk the moment the same person holds both.
Someone who can both create a vendor record and approve payments to that vendor isn't flagged by a normal review, because neither half of that pair looks wrong on its own. It takes a conflict-specific check to catch it, and most reviews never run one.
Here are the 6 conflict patterns that show up in nearly every audit, so you can find them yourself first.
A segregation of duties conflict is never one bad permission. It's two acceptable permissions landing on the same person, and a review that checks permissions one at a time will never catch it.
This is exactly why access reviews and SoD reviews are different exercises, even though they often get bundled into one conversation. You need both, and the second one requires a conflict matrix, not a job-description checklist.
The 6 IFS Cloud segregation of duties conflicts auditors find first
- 1. Create or modify a vendor, plus approve payments to that vendor. The classic procure-to-pay conflict, and one of the separation of duties findings most commonly cited across ERP audits generally.
- 2. Create a purchase order, plus approve that same purchase order. Self-approval risk, letting someone commit organizational spend without any second set of eyes.
- 3. Create or modify a payroll record, plus approve the payroll run. A conflict that turns a single account into everything needed for payroll fraud, start to finish.
- 4. Post a journal entry, plus approve or reconcile that same entry. Undermines the basic integrity of financial reporting, since the person recording a transaction is also the one certifying it's correct.
- 5. Modify price or discount master data, plus approve sales orders at that price. A quiet revenue leakage risk, letting one person set a discount and then approve orders that benefit from it.
- 6. Grant system access, plus approve your own access requests. The meta-conflict. An access-granting process with no segregation built into it is a conflict sitting on top of every other conflict on this list.
Why procure-to-pay tops every list
It's the simplest conflict to create fraud with and the easiest to overlook, since both permissions are common, ordinary parts of a finance role considered separately.
Why journal entry conflicts undermine trust broadly
If the person recording a transaction can also approve it, every downstream number inherits that same lack of independent check, not just the one entry.
Why the access-granting conflict matters most
It's the conflict that lets every other conflict on this list persist undetected, since the person who could fix the access-granting process is the same person benefiting from it staying broken.
Why this needs its own review, not a footnote in the access review
An access review asks "should this person have this permission." An SoD review asks a completely different question: "does this specific combination of permissions, both individually reasonable, create a conflict." Answering the second question requires a conflict matrix checked against every user, not a checklist read one line at a time.
How to actually check for these systematically
Map the known conflict pairs at the Projection and Action level, the same mechanism that actually determines what a user can do in IFS Cloud, not at the level of job titles or Role names.
Run current access for every user against that conflict matrix, flagging anyone who holds both sides of a pair, regardless of whether their job title suggests it's unlikely.
Treat every flag as a genuine decision point, not an automatic removal. Some conflicts are accepted with a compensating control in smaller teams, but that has to be a documented decision, not a default.
An access review checks whether one permission makes sense. An SoD review checks whether two of them, together, don't.
What finding these yourself actually protects you from
An auditor's management letter listing conflicts you could have found and fixed months earlier, with your name attached to the review that missed them.
Real financial exposure, since these six patterns are exactly the mechanisms fraud and reporting errors actually use, not theoretical compliance categories.
A scramble to remediate under audit pressure, instead of a calm, planned conversation about which conflicts to accept, mitigate, or eliminate.
We'll run the conflict matrix against your actual access.
PermissionWorks checks current access for every user against the known IFS Cloud SoD conflict pairs, flagging exactly who holds both sides of a conflict, before an auditor finds it for you.
See how this complements the access reviewFind your SoD conflicts before your auditor does.
Send us your current IFS Cloud role assignments and we'll check them against the known segregation of duties conflict pairs, flagging every user who holds both sides of a conflict.
What is the difference between an access review finding and a segregation of duties finding?
An access review checks whether one permission is appropriate for one person. A segregation of duties finding is about the combination: two permissions that are each individually fine but create a conflict when the same person holds both, like creating a vendor and approving payments to that vendor.
Why do these conflicts survive normal access reviews?
Because a normal review checks permissions one at a time against a job description. Neither half of an SoD conflict looks wrong in isolation, so a review that does not specifically cross-reference permission combinations misses the actual risk.
What is the most common SoD conflict found in IFS Cloud environments?
Procure-to-pay conflicts, typically someone who can both create or modify vendor records and approve payments, are among the most frequently cited findings across ERP audits generally, IFS Cloud included.
How do you actually check for these systematically?
Map out the known conflict pairs at the Projection and Action level, then run current access against that conflict matrix for every user, rather than relying on someone remembering to check manually during a routine review.
Check the combinations, not just the permissions
Six conflict patterns, none of them visible from a single permission on its own. All six visible the moment you check combinations against a real conflict matrix.
Run that check before an auditor does. It's the same information either way, just a much better time to find it.