SoD on paper is theory. SoD on transactions is control.
Segregation of duties (SoD) means no single person can execute, record and approve the same transaction. Most SAP tools check it in theory, on roles and authorisations. RiskForge checks it in reality, on every actual transaction, with the option to stop a critical conflict before it posts.
The gap between access and behaviour.
To be clear about scope first: RiskForge includes the full role-based conflict analysis you would expect from a GRC suite. The rule matrix, critical authorisations, conflict simulation, the complete classic checklist. The point of this page is that RiskForge does not stop there.
Role-based SoD analysis answers one question: who holds conflicting authorisations? That check is necessary, and it is structurally blind to the violations that matter most. The clerk whose temporary emergency access never got revoked. The approval done as a favour in thirty seconds. The manager who approves her own initiative through a colleague's login. On paper all of this looks clean. In the transaction stream it is visible.
RiskForge evaluates segregation of duties where it actually succeeds or fails: on the executed transaction. Who initiated, who approved, who released, matched against eligibility, history and behavioural baselines.
The conflicts that hurt.
Vendor master + payment
The same person changes a vendor's bank details and releases a payment to it. This is the classic redirection fraud. RiskForge links the two events even days apart, and can hold the payment.
Journal entry + approval
Self-approved postings, or approvals by someone whose approval rights are days old. The approval chain is checked against the change history of the approver list itself.
Developer + production
The developer of a change approves or releases their own transport into production. RiskForge correlates transports with commits, tickets and approver eligibility.
Purchasing + goods receipt
The same identity orders and confirms receipt, which is the standing invitation to phantom purchases. Caught on the transaction pair, not the role matrix.
From finding to evidence.
Every detected conflict carries its full context: the transactions, the people, the timing, and prior occurrences of the same pattern. It lands in the evidence vault, ready for the auditor's package. Where role-analysis tools hand the auditor a list of theoretical conflicts to investigate manually, RiskForge hands them resolved cases with documentation.
Frequently asked questions
What is segregation of duties (SoD)?
Segregation of duties is the control principle that no single person should be able to execute, record and approve the same transaction. In SAP terms: whoever creates a vendor should not also change its bank details and release payments to it. SoD prevents both fraud and undetected error by forcing a second pair of eyes.
Why is role-based SoD analysis not enough?
Role analysis finds who could violate SoD in theory. It cannot see violations that happen inside formally clean access, such as shared credentials, emergency access, approvals waved through, or a recently authorised approver rubber-stamping a colleague's change. Transaction-level monitoring evaluates what actually happened.
Can SoD conflicts be blocked in real time?
Yes. In RiskForge's enforcement mode, a transaction that completes a critical SoD conflict, for example a payment released by the same person who changed the vendor's bank account, can be held before it posts and routed to an eligible approver.
How does RiskForge handle SoD in the change process?
RiskForge checks segregation of duties in IT change management too: whether the developer of a transport also approved or released it, whether the approver was eligible, and whether approvers were added to the approver list suspiciously close to the approval. The check draws on Jira, ServiceNow, SAP GRC and the transport logs together.
See RiskForge on your own processes.
A 30-minute walkthrough against realistic SAP scenarios: payment runs, journal entries, transports. No slides, just the actual product.