PME and Mid-size compliance teams often have the same uncomfortable reality: your policies say “segregation of duties”, but your operating model says “two people for six critical steps”. Then an auditor (internal, external, AFA-style review, ISO certification audit) asks a simple question: show me how you prevent one person from initiating, approving, and paying in the same workflow.
A practical segregation of duties matrix is the fastest way to move from intentions to evidence. Done well, it also reduces training fatigue because it replaces generic rules with role-based, process-based guardrails.
Why segregation of duties breaks down in mid-size firms
In theory, segregation of duties (SoD) is straightforward: separate initiation, approval, execution, recording, and review. In practice, small and mid-size groups in un into four predictable failure modes:
- Role overload: the same manager is “business owner”, “budget approver”, and “invoice approver”.
- Tool fragmentation: ERP approvals are separated, but vendor creation sits in a shared mailbox, and evidence sits in personal folders.
- Matrix drift: the SoD matrix exists, but no one can prove it is enforced (access rights, workflow configuration, exception approvals).
- Local variations: local sites apply the same principle differently, with inconsistent thresholds and unclear compensating controls.
SoD is not only an anti-fraud concept. For anti-corruption and competition compliance, it is also a program effectiveness signal: it shows you can prevent, detect, and escalate conflicts of interest, improper third-party onboarding, non-compliant discounts, and “friendly” approvals.
What “good” looks like for audits
The details vary by framework, but reviewers generally look for the same chain: risk scenario, control design (including SoD), evidence, testing, remediation.
The five-step method to build a segregation of duties matrix
This method is designed for teams with limited headcount, multiple countries, and frequent audits.
Step 1: Pick the processes that actually create exposure
Start with 6 to 10 processes where SoD failures create a plausible legal or regulatory risk, not only a theoretical risk.
A practical starter set for small and mid-caps:
Process | Typical exposure if SoD fails | Why it matters in audits |
|---|---|---|
Third-party onboarding | Shell vendors, conflicted intermediaries, incomplete due diligence | Links to due diligence expectations and accounting controls |
Purchase to pay (P2P) | Fake invoices, split payments, bypassed approvals | Core “books and records” integrity signal |
Gifts, hospitality, travel | “Friendly” approvals, thresholds bypassed | Easy to test, often reviewed |
Donations, sponsorships | Hidden benefits, local pressure, reputational risk | High scrutiny in anti-corruption programs |
Sales discounts and rebates | Off-book benefits, side deals, distributor misuse | Relevant for anti-corruption and competition risk |
Hiring, promotions, bonuses | Conflicts of interest, undue influence | Governance and culture indicator |
Keep the first version narrow. A matrix that covers everything usually proves nothing.
Step 2: Define roles (not names) and map them to systems
Write roles the way your business operates, then map each role to:
- The system(s) used (ERP, expense tool, CRM, procurement tool)
- The permission set (create, approve, release, modify master data)
- The evidence source (workflow log, access report, register entry)
Examples of role definitions that work well across France and Spain:
Role | Scope | What to avoid in the definition |
|---|---|---|
Requester | Creates a purchase request or expense claim | “Anyone in operations” (too broad to audit) |
Budget owner | Approves budget availability | Mixing budget approval with payment release |
Procurement | Runs sourcing and issues PO | Owning vendor creation without controls |
AP accountant | Processes invoices | Ability to create vendors and process invoices |
Treasury | Releases payments | Approving their own beneficiaries |
Compliance or legal reviewer | Reviews high-risk third parties, donations, sensitive spend | Being the operational approver by default |
Step 3: Write “incompatible duty pairs” first
Instead of trying to fill a giant matrix immediately, start with a short list of non-negotiable conflicts that your auditors will recognize.
Use a table like this, and treat it as your SoD rulebook.
Duty a | Duty b | Why incompatible | Compensating control if separation is impossible |
|---|---|---|---|
Create vendor (master data) | Approve vendor | Enables self-approval of a risky third party | Independent periodic vendor master review, with documented sampling |
Create vendor | Process invoice | Enables fake vendor and fake invoice chain | Automated duplicate checks plus independent review of new vendors |
Approve invoice | Release payment | Enables “approve and pay” without challenge | Dual payment release, or treasury release + post-payment review |
Submit expense | Approve expense | Enables personal benefit without review | Manager approval enforced by system, plus audit sampling |
Own contract negotiation | Own due diligence sign-off | Can “push” an intermediary through | Second-line review above thresholds or red flags |
Configure approval workflow | Be beneficiary/requester | Can design a bypass | Change control with peer review and audit trail |
This list is usually easier to agree on with finance, procurement, and IT than a full matrix.
Step 4: Build the matrix around “initiate, approve, execute, record, review”
Now you can translate the rulebook into a matrix per process. Keep it readable and enforceable.
Below is a practical example for third-party onboarding and payment, which is often a high-value audit area.
Step | Initiate | Approve | Execute | Record | Review |
|---|---|---|---|---|---|
Vendor onboarding request | Business requester | Procurement or budget owner | N/A | N/A | Compliance or legal (risk-based) |
Due diligence (risk-based) | Procurement | Compliance or legal | N/A | N/A | Compliance lead periodic QA |
Vendor creation in ERP | AP or master data clerk | Finance manager | N/A | ERP record | IT access review quarterly |
PO issuance | Procurement | Budget owner | Procurement | ERP record | Procurement manager sampling |
Invoice processing | AP accountant | Budget owner | N/A | ERP record | Finance controller sampling |
Payment release | N/A | N/A | Treasury (dual release if possible) | Bank file + ERP | Finance controller post-payment analytics |
Two notes that matter in small and mid-size firms:
- You do not need five different people. You need incompatible steps not held by the same person, plus a compensating control when headcount is tight.
- “Review” is where many small and mid-size teams win audits. It is also where many fail because they cannot show evidence of a real review cadence.
Step 5: Create an exceptions register (and treat it as an audit element)
If exceptions are informal, they will be seen as control failures. If exceptions are governed, they can be accepted as proportional.
Use an exceptions register template like this:
Exception id | Process | Conflict | Reason | Compensating control | Owner | Start date | End date | Evidence link |
|---|---|---|---|---|---|---|---|---|
EX-2026-001 | P2P | Invoice approval + payment release | Small site, 2-person finance | Dual bank release + monthly post-payment review | Finance director | 2026-02-01 | 2026-06-30 | Folder or ticket reference |
The “evidence link” can be a shared location, a ticket ID, or a control record, the key is that it is stable and retrievable.
A decision rule for compensating controls (when you cannot segregate)
Auditors do not expect infinite headcount. They do expect that you recognize conflicts and reduce risk in a traceable way.
Use this decision rule to pick compensating controls that are credible:
If the same person must… | Minimum compensating control | What “good evidence” looks like |
|---|---|---|
Create vendor and process invoices | Independent review of all new vendors for the period | Report of new vendors, reviewer sign-off, tracked findings |
Approve and pay | Dual release at bank, plus post-payment analytics | Bank authorization log, monthly review memo with sample |
Own due diligence and approval | Second-line spot checks based on risk triggers | Sampling plan, results, remediation actions |
Configure workflows and submit requests | Change control with peer review | Ticket with approval, before/after config export |
How to test SoD effectiveness (and prove it)
A matrix is control design. Audit readiness requires control effectiveness testing.
A lightweight quarterly test plan that works in most mid-size firms:
Test | Frequency | Sample | Pass criteria | Evidence to retain |
|---|---|---|---|---|
Access rights review for incompatible permissions | Quarterly | All users with sensitive permissions | No unapproved conflicts, exceptions documented | Access report, reviewer sign-off, exception list |
New vendor review | Monthly or quarterly | 100% or risk-based sample | Due diligence present where required | Vendor list, check results, follow-ups |
Payment run review | Monthly | 1 to 2 payment runs | Dual release performed, anomalies investigated | Bank log, review checklist, anomalies notes |
Gifts and hospitality approvals | Quarterly | Risk-based sample | Approvals follow thresholds, no self-approval | Register extract, sample testing sheet |
If your evidence is spread across tools, build a repeatable way to collect it. For teams with internal tooling or API-based workflows, it can be useful to generate consistent test runs and logs using a local flow runner such as DevTools – local-first API testing & flow automation to record approval paths, export reviewable flows, and produce test reports that you can archive.
A short implementation checklist
- Define the 6 to 10 in-scope processes and risk scenarios.
- Agree on the incompatible duty pairs (the SoD rulebook).
- Map roles to systems and permission sets, then identify conflicts.
- Decide which conflicts are fixed by workflow, which require compensating controls.
- Create the exceptions register and name an owner for each exception.
- Set the first quarterly test plan and pre-book the review meeting.
If you do only one thing for audit readiness, do this: make sure every rule in your SoD rulebook has a corresponding evidence source.
How naltilia can help
If your main pain is not defining segregation of duties, but operationalizing it with evidence, Naltilia can help centralize and automate the work around risk and controls. Teams typically use it to connect SoD requirements to risk assessments, assign owners, track remediation actions automate data collection for control tests, and maintain audit-ready records across entities. It can also support structured workflows for approvals and policy updates so your matrix stays aligned with how the business actually operates. Contact us if you want to see how Naltilia works.
This article is general information, not legal advice.
