Segregation of Duties in ERP Finance: Build a Conflict Matrix and Exception Process

Quick answer

Build an ERP segregation-of-duties matrix around incompatible actions—not job titles. Identify who can maintain suppliers, enter invoices, approve payments, post journals and administer access. Then test those permissions together. Remove unnecessary combinations; where separation is impractical, document an approved exception with a specific independent control, an expiry and retained review evidence. GAO’s internal-control guidance explicitly calls for alternative controls when staffing or other constraints prevent segregation. (gao.gov)

This guide provides a vendor-neutral working method for controllers, finance managers and ERP security teams. The matrix and exception record below are illustrative templates, not universal compliance requirements. Microsoft Dynamics 365 documentation supplies a product example; confirm behavior in your own ERP edition, release and configuration before changing access.

1. Define the financial risk before listing roles

Start with a question: What could one person initiate, authorize and conceal without an independent check?

GAO’s 2025 Green Book describes segregation across authority, custody and accounting responsibilities. It also recognizes that segregation cannot eliminate collusion. The Green Book establishes federal internal-control standards; this article uses its principles as a design reference, not as a claim that every private business must follow federal requirements. (gao.gov)

For your first workshop, map two complete processes:

• Supplier to payment: supplier creation, bank-detail changes, invoice entry, invoice approval, payment preparation, payment approval and bank release.
• Journal to reporting: journal preparation, approval, posting, correction, reconciliation and review.

Keep actions distinct. “Process payments” is too broad for a useful control discussion. Ask whether the permission allows someone to prepare a proposal, approve it, generate a payment file or release funds through the bank.

Write a risk statement for each proposed conflict. For example:

A user who can change supplier bank details and release payments could redirect a legitimate payment without another person checking the destination.

That statement gives the team something concrete to prevent or detect.

2. Inventory effective permissions, not role labels

A role called “Accounts Payable Clerk” does not, by itself, establish what its holder can do. In Dynamics 365 finance and operations apps, roles contain duties, duties contain privileges, and privileges contain permissions. Microsoft also documents that administrators can modify security definitions. Examine the underlying access rather than treating a standard-sounding name as assurance. (learn.microsoft.com)

Create an access inventory with these fields:

Field	What to capture
Identity	Named user, administrator, integration identity or other account
Business action	Create supplier, change bank details, post invoice, release payment
Access source	Role, group, custom privilege or other supported assignment path
Scope	Legal entity, bank account, transaction type and relevant restrictions
Approval capability	Approve own work, approve others, delegate or change routing
Related access	Bank portal, supplier portal or connected application
Evidence	Export date, configuration reference and test result

Trace the complete route to each sensitive action. Include imports and integrations in the review plan, rather than assuming that a blocked screen proves an action is impossible. Microsoft’s security documentation identifies service operations as entry points alongside user-interface access. (learn.microsoft.com)

Record both configured access and observed test behavior. If the two disagree, investigate before approving the access model.

3. Build an action-based conflict matrix

Use the following as a starter matrix. These are proposed risk scenarios and control responses, not a vendor’s predefined conflict catalogue. Adapt them to your payment methods, journal workflows and organizational structure.

Rule	Action A	Incompatible action B	Risk to assess	Proposed response
SOD-01	Maintain suppliers or supplier bank details	Approve or release supplier payments	Redirect payments	Separate maintenance from approval and release; independently verify bank changes
SOD-02	Enter supplier invoices	Approve those invoices	Create and authorize unsupported liabilities	Prevent self-approval; route supporting documents to an independent approver
SOD-03	Prepare payment batches	Give final payment authorization	Prepare and authorize an improper payment	Independent authorization of the final batch
SOD-04	Prepare manual journals	Approve or post those same journals without independent approval	Record unsupported adjustments	Independent approval before posting, or a documented alternative review
SOD-05	Post cash or bank adjustments	Perform the final reconciliation review	Conceal inappropriate adjustments	Assign final review to someone independent of posting
SOD-06	Administer finance access	Approve one’s own access or certify its appropriateness	Grant and retain excessive permissions	Independent business approval and access certification
SOD-07	Change approval workflows	Initiate or approve affected transactions	Weaken authorization controls	Separate configuration approval from transaction processing

For each rule, add an owner, scope, risk rating, permission mapping and exception reference.

Distinguish two kinds of rule:

• Access-based conflict: holding both capabilities is prohibited.
• Transaction-based restriction: someone may perform both functions generally, but must not approve their own transaction.

Do not automatically dismiss a conflict because permissions apply to different companies. First check whether shared suppliers, centralized payments or cross-company responsibilities connect the exposure.

Conversely, do not label every combination a failure. Document why a restriction genuinely prevents the risky action.

4. Configure detection and test what it actually covers

If your ERP provides segregation-of-duties rules, translate the approved matrix into its supported security objects. Keep the business rule ID alongside the technical mapping.

In Dynamics 365, Microsoft documents rules between two duties, including severity, risk and mitigation fields. Creating a rule does not validate existing access: compliance must be checked after creating or modifying it. (learn.microsoft.com)

Microsoft distinguishes role validation from user-role assignment validation. Its documentation also states that conflicts are not currently verified for users assigned roles through Active Directory Domain groups. Treat that documented limitation as a reason to check assignment paths separately—not as evidence that group-based access is safe. (learn.microsoft.com)

Use a nonproduction environment and authorized test identities. Suggested tests include:

1. Supplier maintenance succeeds for the designated maintainer.
2. That identity cannot approve or release a payment.
3. An invoice preparer cannot approve their own invoice.
4. Journal posting follows the approved review design.
5. Delegation and absence-cover arrangements preserve the intended separation.
6. Removing temporary access actually removes the sensitive capability.

Retain expected results, actual results, identity, scope and supporting evidence. Test both permitted work and prohibited combinations. Microsoft recommends sandbox testing when assessing security changes after service updates. (learn.microsoft.com)

5. Design compensating controls for small teams

When staffing prevents separation, design the alternative around the exact risk. GAO calls for alternative control activities where segregation is impractical and emphasizes the precision and timing of controls. A vague promise that “management reviews everything” does not specify an executable check. (gao.gov)

For a proposed supplier-maintenance exception, define:

• Population: every supplier and bank-detail change during the exception.
• Reviewer: someone who did not make those changes.
• Procedure: compare old and new values with authorized supporting evidence; verify bank changes through an established independent contact channel.
• Timing: before payments to changed bank details are released.
• Evidence: change report, verification record, payment reference and dated decision.
• Failure response: hold the affected payment and escalate discrepancies.

For journals, propose a review of entries posted by the conflicted user, including support, accounts, amounts and approval evidence. Decide explicitly whether review must precede posting or whether a documented detective review is acceptable for the assessed risk.

Give the reviewer a reliable way to establish completeness. Record report filters, period, company scope and record count; do not rely solely on a list assembled by the person being reviewed.

If no suitably independent reviewer is available, escalate the unresolved risk. An exception form cannot substitute for a control nobody can perform.

6. Document a temporary-access exception: worked example

Illustrative scenario: An invoice-entry employee must cover supplier maintenance during a colleague’s absence. This creates SOD-01 exposure if that employee also has payment authority, and a separate supplier-creation/invoice-entry risk even without payment authority.

Use a record like this before granting access:

Exception field	Illustrative entry
Reference	EX-014
Business need	Temporary supplier-maintenance cover
User and scope	Named employee; specified production legal entity
Existing access	Supplier invoice entry
Temporary access	Supplier maintenance only
Excluded access	Invoice approval, payment approval, bank release and security administration
Window	Five business days; exact start/end timestamps and time zone required before approval
Risks	Unsupported suppliers or invoices; unauthorized bank changes
Approval	Independent finance risk owner; security administrator implements
Controls	Independent review of all supplier changes; independent invoice approval; bank-change verification before release
Evidence	Approved request, before/after access exports, change report, verification records and review sign-off
Expiry	Scheduled removal where supported; otherwise a named administrator and tracked removal task
Closure	Removal evidence, post-removal test and completed transaction review

Suppose the illustrative change report contains six supplier changes, including two bank-detail changes. The reviewer checks all six against support and verifies both bank changes before related payments are released. These numbers describe the example only; they are not a recommended sample size.

At expiry, remove the temporary permission and test that supplier maintenance is blocked. Review activity performed during the window even after access ends.

In Dynamics 365, allowing a conflicting role assignment requires an override reason. Treat that system reason as one reference within the fuller exception record—not as the entire approval and control process. (learn.microsoft.com)

7. Review access and close common control gaps

Set a documented review schedule based on risk, and add event-driven reviews after transfers, departures, role changes, workflow changes and system updates. For each review, reconcile the current user population, permission inventory, conflicts and exception register.

Use these practical checks:

Common mistake	Check to perform
Reviewing role names only	Trace sensitive actions to their permission sources
Assuming separate roles mean separate people	Evaluate each person’s combined access
Treating payment approval as bank release	Examine ERP and bank authorization separately
Assuming a clean conflict report proves safety	Confirm rule coverage, scope and assignment-path limitations
Granting broad administrator access for absence cover	Identify the narrow capability actually needed
Renewing exceptions automatically	Reassess need, reviewer capacity and residual risk
Keeping only a reviewer’s signature	Retain the population, work performed and discrepancy resolution

For review evidence, retain dated exports, reviewer decisions, removal tickets, test results and unresolved issues. Assign each issue an owner and target date.

The practical deliverable is a connected set of records: an action-based matrix, verified permission mappings, test evidence and controlled exceptions. Start with supplier-to-payment and manual-journal risks, then expand coverage without losing the detail that makes each rule testable.