Segregation of duties (SoD) is one of the first areas auditors test in an ERP environment. This is not only an IT topic. It is a core internal-control topic tied to financial reliability and operational risk reduction.
In many organizations, the issue is not a lack of SoD rules on paper. The issue is the gap between the theoretical role matrix and the rights that are actually active in the ERP, especially after years of changes, exceptions, and urgent access requests.
This article gives you a 12-control SoD checklist to implement before your annual audit, with one practical objective: secure critical flows without slowing down operations.
Why ERP audits still fail on SoD
Audit findings often look different on the surface, but the root cause is usually the same:
- Roles accumulated over time without an end-to-end review.
- Emergency access never revoked.
- Manual controls performed without traceable evidence.
- No clear ownership between IAM and ERP governance.
When these weaknesses combine, auditors see elevated risk of internal fraud, accounting error, or undetected manipulation. This goes beyond compliance; it directly affects the quality of financial steering.
12 SoD controls to deploy before the audit
1. Map sensitive processes and transactions
Start with what materially matters: procurement, vendor management, payments, sales, credit notes, general ledger, fixed assets, and treasury.
Objective: link each process to its key ERP transactions, then identify incompatible action pairs (for example, vendor creation plus payment approval).
Without this mapping, SoD stays abstract and cannot be operated effectively.
2. Formalize a version-controlled SoD matrix
Your SoD matrix should be a living, approved reference with version history. It should define:
- The business function in scope.
- Authorized and prohibited ERP transactions.
- Blocking conflicts.
- Tolerated conflicts with compensating controls.
A non-versioned matrix quickly becomes audit-weak, because nobody can prove which rule was active when a specific transaction occurred.
3. Strictly separate creation and approval of third parties
Vendor and customer master data are high-risk zones. The same user should not be able to create or edit a third party and then approve related financial transactions.
Minimum controls:
- Separate third-party master maintenance from accounting validation.
- Separate bank detail maintenance from payment execution.
- Enforce a documented review for any sensitive IBAN/bank account update.
4. Prevent one user from controlling PO-receipt-invoice-payment end to end
The baseline procurement control is to split the P2P chain:
- Purchase order creation.
- Goods or service receipt.
- Invoice approval.
- Payment release.
In smaller companies, full separation is not always realistic. When that is the case, at least restrict role combinations in the ERP and document a monthly compensating review by an independent manager.
5. Tighten controls over manual general-ledger entries
Manual journal entries can correct legitimate issues, but they are also a channel for earnings manipulation or expense shifting.
Implement:
- Restricted manual posting rights.
- Separate approval for non-standard journal entries.
- Active audit trail with mandatory reason codes.
Auditors will focus in particular on period-end entries and unusual reversals.
6. Separate configuration rights from operational rights
A functional admin who can both change control settings and execute critical business transactions creates significant risk.
Good practice:
- ERP configuration profiles do not post operational entries.
- Business user profiles do not access security settings, workflows, or approval-rule parameters.
This boundary is often overlooked during migrations and data-takeover projects.
7. Govern privileged and emergency access
Superuser accounts are useful during incidents but risky in day-to-day operations.
Minimum requirements:
- Privileged access vault (or equivalent control).
- Time-limited elevation.
- Mandatory business justification.
- Post-use review.
Emergency access without logs is a major audit weakness.
8. Enforce periodic access recertification
SoD is never a one-off task. Role models drift as teams change.
Run quarterly or semiannual recertification led by business and finance, with explicit sign-off:
- Who keeps access.
- Who needs scope changes.
- Who must be removed immediately.
Keep signed or timestamped evidence. Without evidence, auditors will treat the control as ineffective.
9. Automate detection of active SoD conflicts
A one-time manual check is not enough. You need recurring scans of conflicts between defined roles and effective assigned rights.
Expected output:
- Open conflict list.
- Severity level.
- Remediation owner.
- Target closure date.
Even a structured monthly export is better than ad hoc checks with no history.
10. Manage SoD exceptions formally
Some exceptions are legitimate (temporary absence, seasonal peak, organizational transition). The issue is not the exception itself; the issue is lack of structure.
Each exception should include:
- Business rationale.
- Exact scope.
- End date.
- Named approver.
- Linked compensating control.
An exception without expiry becomes an unofficial permanent rule.
11. Build an audit-ready evidence pack
Before the audit, prepare a single evidence file containing:
- Current approved SoD matrix.
- Privileged accounts and recent usage.
- Signed access reviews.
- Open and closed exceptions.
- Conflict and remediation logs.
Goal: reduce scramble during fieldwork and avoid improvised responses.
12. Assign one accountable SoD owner
SoD programs frequently fail because accountability is diluted. IT assumes finance owns it; finance assumes IT owns it.
Assign one accountable owner (typically internal control, finance transformation, or ERP PMO) with a clear mandate:
- Maintain the matrix.
- Arbitrate conflicts.
- Track remediation.
- Prepare audit-committee reporting.
Without clear governance, even good SoD tooling drifts over time.
30-day execution plan before audit
If your audit window is near, use a pragmatic sequence:
- Week 1: scope critical processes and extract active role assignments.
- Week 2: update the SoD matrix and assess major conflicts.
- Week 3: remediate critical conflicts and formalize exceptions.
- Week 4: finalize the evidence pack and rehearse finance/IT review.
This will not replace a long-term internal-control program, but it will significantly reduce immediate non-compliance risk.
Common mistakes to avoid
Three recurring failures appear in ERP audits:
- Treating SoD as documentation only, without actual rights cleanup.
- Using organizational complexity as an excuse for missing rules.
- Waiting for audit kickoff to start conflict cleanup.
The right approach is to run SoD as a continuous governance process, not as a year-end deliverable.
What CIO and CFO should monitor together
ERP SoD works when governance is shared:
- The CIO secures role architecture, traceability, and control automation.
- The CFO validates that rules address real financial risk.
- The executive sponsor arbitrates exceptions when operations and control requirements conflict.
This alignment avoids a common double failure: an ERP that is secure but unusable, or efficient but out of control.
Operational takeaway
An annual audit is not passed with slide decks. It is passed with cleaned access rights, governed exceptions, and usable evidence.
These 12 controls provide a realistic baseline for SMBs and mid-market organizations that want stronger ERP control without creating heavy bureaucracy.
Download our ERP evaluation scorecard — 30 criteria to benchmark 3 vendors side by side.
