Quick answer: Give each person only the ERP access their work requires, and separate conflicting responsibilities wherever possible. When staffing prevents full separation, document the exception and assign an independent, evidence-based review. Start with supplier bank details, payment release and security administration—not just job titles. These steps apply the principles of least privilege and segregation of duties described in NIST guidance. (csrc.nist.gov)
For finance and IT leaders, the practical question is: Can one person make a sensitive change and complete the resulting transaction without another person checking it?
Use the following method to design a manageable control process. The role names, approval amounts and workflow below are illustrative recommendations, not product defaults or a compliance guarantee.
1. Identify conflicting actions across the whole payment process
Segregation of duties means identifying responsibilities that should be separated and assigning access accordingly. NIST also cautions that conflicts can span systems: reviewing ERP access alone may miss permissions held in another application. (csrc.nist.gov)
Start with one process, such as purchasing through payment. List who can perform each sensitive action in the ERP, connected applications and banking portal.
Use this starter list to identify combinations requiring attention:
| Combination to investigate | Risk to consider |
|---|---|
| Change supplier bank details and release payments | A changed destination could receive an independently unverified payment |
| Enter an invoice and approve that invoice | The preparer could authorize their own transaction |
| Prepare a payment file and replace it after approval | The released file could differ from the approved batch |
| Grant access and review the resulting access | The administrator could assess their own changes |
| Perform transactions and control their audit evidence | The reviewer might lack reliable evidence |
Treat these as investigation prompts, not a universal conflict catalog. Record the exact action, system, company or business unit, assigned person and intended reviewer.
2. Build roles around tasks, then inspect combined access
Create a small set of task-based roles before assigning people to them. For a payment process, useful starting points might be:
- Supplier maintenance.
- Invoice preparation.
- Business approval.
- Payment preparation.
- Payment release.
- Read-only review.
- Security administration.
For each role, specify what it may create, change, approve, post or export—and which companies or records it covers. Then inspect each person’s combined access, including direct assignments, groups and temporary permissions.
Product terminology matters. In Dynamics 365 finance and operations apps, roles contain duties, and duties contain privileges. Microsoft recommends using duties to grant access. A familiar role name is therefore not a substitute for inspecting its underlying permissions. (learn.microsoft.com)
Practical check: In a test environment, sign in as a representative user. Confirm both that required work succeeds and that prohibited actions fail. Do not test only whether the right menu appears.
Product examples here use Microsoft documentation checked on October 26, 2026. Confirm behavior in your deployed application, version, localization and configuration; these examples are not interchangeable across ERP products.
3. Define approval rules and test their boundaries
Write an approval policy that answers five questions:
- What needs approval: a purchase, invoice, supplier change or payment?
- Who may approve it?
- Which amount and currency determine the approval route?
- What changes require renewed approval?
- Who acts when the approver is unavailable?
Keep business approval separate from payment release in the policy. For example, approval that an invoice is legitimate should not be treated as proof that the final payment destination was checked.
Business Central’s documented approval-user setup supports amount limits and substitute approvers. Microsoft specifically warns against making the same user both requester and approver in a workflow user group: that configuration can automatically approve the user’s requests. (learn.microsoft.com)
Use synthetic transactions to test:
- Amounts just below, exactly at and just above each threshold.
- A requester attempting self-approval.
- An absent approver and their substitute.
- Changes to the amount or supplier after approval.
- Rejected, cancelled and resubmitted requests.
- Any import or integration route used by the business.
Record expected and actual results. If the system cannot enforce a policy rule, identify the additional control explicitly rather than assuming the workflow covers it.
4. Worked example: supplier creation through payment release
Consider a hypothetical organization with an accounts payable clerk, a finance manager and a business owner. An IT provider administers access.
Assume the organization chooses this illustrative policy:
- The clerk maintains suppliers, enters invoices and prepares payments.
- The manager reviews supplier changes and approves invoices up to $5,000.
- The owner approves invoices above $5,000 and releases all payments.
- The IT provider cannot approve invoices or release payments.
The $5,000 threshold is an example, not a recommended standard.
| Step | Proposed responsibility | Evidence to retain |
|---|---|---|
| Create a supplier or request a bank-detail change | Clerk enters; manager independently verifies | Request, verification record and change history |
| Enter a $7,500 invoice | Clerk prepares | Invoice and supporting purchasing or receipt records |
| Approve the invoice | Owner approves because it exceeds the example limit | Approver identity, decision and timestamp |
| Prepare the payment batch | Clerk prepares | Batch reference, recipients and amounts |
| Release payment | Owner checks the final destination and amount | Release record linked to the reviewed batch |
| Review the completed cycle | Manager reviews changes and bank activity | Dated review and exception follow-up |
This design deliberately allows the clerk to maintain suppliers and prepare payments. The proposed safeguard is independent verification before release—not a claim that the conflict has disappeared.
Suppose the clerk changes a supplier’s bank details after invoice approval. Under this proposed policy, invoice approval is insufficient: the owner pauses release until the manager verifies the new destination using previously established contact information.
Also test whether the payment file can be replaced after review. If it can, redesign the release step so the releaser checks the final file or bank instruction, not merely an earlier ERP report.
5. Document compensating controls as specific work
Where you cannot remove a conflict, specify how another person will address the risk. Microsoft’s finance and operations documentation gives more detailed reviews, managerial review and sharing resources with other departments as examples of mitigation. (learn.microsoft.com)
For each exception, create a short record containing:
- Conflict: the exact permissions held together.
- Reason: why separation is currently impractical.
- Reviewer: someone independent of the activity being reviewed.
- Scope: which changes or transactions must be examined.
- Timing: before release, after each payment run or another justified interval.
- Evidence: what the reviewer retains.
- Escalation: what happens when something is unexplained.
- Expiry: when the exception must be reconsidered.
Replace “owner reviews payments” with an instruction such as: “Before release, the owner checks every new or changed supplier destination in the batch against the independent verification record.”
Distinguish preventive checks from later detection. A monthly review may be useful, but do not describe it as equivalent to checking a changed destination before funds leave.
If no independent reviewer is available, escalate the unresolved risk rather than relabeling self-review as a compensating control.
6. Keep privileged access separate and temporary
Treat access administration as its own responsibility. Identify who can change roles, workflow rules, approval limits, integrations and logging settings.
Microsoft’s Azure identity guidance recommends separate accounts for critical administrative tasks, avoiding routine email and browsing with those accounts, and using phishing-resistant multifactor authentication. It also describes controls for managing privileged access. These are identity-management practices to coordinate with ERP security—not proof that an ERP workflow is protected. (learn.microsoft.com)
For a small team, use this practical administrative-access record:
- Named administrator and business sponsor.
- Approved task and required permissions.
- Start and end time.
- Production changes made.
- Evidence reviewed afterward.
- Confirmation that temporary access was removed.
Where supported, prefer time-limited elevation over permanent broad access. Have qualified security personnel design and test emergency access so a control change does not lock out every administrator.
Common mistake: Giving an implementation consultant unrestricted access without an end date. Make access removal part of the support handover checklist, not an informal reminder.
7. Collect evidence that supports an actual review
Decide what the reviewer needs before configuring logging. For the example workflow, request evidence connecting:
- Supplier creation and bank-detail changes.
- Invoice approvals and subsequent edits.
- Payment preparation and release.
- Role assignments and workflow changes.
- Exceptions and their resolution.
Business Central’s change log requires selection of tables and fields and activation of logging. Microsoft cautions that extensive logging can affect performance and database size, recommending selective tracking of important fields. Its documentation also notes that changes appear in Change Log Entries after the user’s session restarts. Do not assume this log is instantaneous or covers every activity. (learn.microsoft.com)
Test evidence collection using a synthetic supplier change. Can the reviewer identify the actor, time, record and old and new values? Can they connect that change to the payment reviewed?
Protect retained evidence from unauthorized alteration or deletion; NIST addresses that protection separately from generating audit records. (csrc.nist.gov)
A useful review record states what was checked, which exceptions were found, what action followed and who completed the review.
8. Run an access review that ends with verified changes
Choose a documented, risk-based review schedule and add reviews after departures, job changes, major configuration changes or emergency access. NIST guidance calls for reviewing privileges at an organization-defined frequency; it does not provide a universal ERP review interval. (nvlpubs.nist.gov)
Use this checklist:
- Every account has an identified owner and current purpose.
- Departed users and expired external access are addressed.
- Changed responsibilities are reflected in access.
- Direct, group-based and temporary assignments are included.
- Supplier, invoice, payment and administrative conflicts are assessed.
- ERP permissions are checked alongside banking and integration access.
- Approvers, substitutes and approval limits remain appropriate.
- Exceptions have evidence, an owner and a reconsideration date.
- Access-removal decisions have been implemented and verified.
- Representative allowed and prohibited actions have been retested.
For Dynamics 365 finance and operations apps, Microsoft says to validate existing roles and user-role assignments after adding or changing segregation-of-duties rules. Its documentation also states that conflicts are not currently verified for users assigned roles through Active Directory Domain groups. Include that limitation in the review where applicable. (learn.microsoft.com)
Finish with a closed decision trail: retain, remove, narrow or approve a documented exception. The objective is not a spreadsheet with every row marked “reviewed,” but access that matches today’s responsibilities and controls that someone demonstrably performs.