Quick answer: Test what each user can actually do—not what their role is called. Map incompatible activities, assign realistic sandbox accounts, and run both permitted and prohibited transactions. Check approval boundaries, self-approval, delegation and payment release separately. Retain evidence of the user, configuration, transaction and outcome.
A finance ERP acceptance test should answer two questions: Can authorized users complete their work, and are unauthorized actions stopped? For a documented example, Microsoft separates security roles, duties, privileges and permissions; workflow configuration then determines approval behavior. Test both layers rather than treating either as sufficient. (learn.microsoft.com)
The following is a proposed test plan for controllers, finance managers and ERP implementation teams. Product-specific examples reference Dynamics 365 Finance and its finance-and-operations platform documentation. They are not instructions for Business Central or a promise that another ERP has equivalent controls.
1. Prepare a safe sandbox and realistic test identities
Before testing, agree on the policy the configuration must enforce. Record who may maintain vendors, enter invoices, approve spending, prepare payments and authorize release. Finance should approve these expectations before IT builds the scripts.
Prepare:
- An isolated test environment: Use synthetic vendors, invoices and bank details. Disable live payment transmission and redirect outbound notifications.
- Named test accounts: Give each account the intended production role combination and organizational scope. Keep configuration administrators separate from business testers.
- A configuration baseline: Record the application version, enabled features, customizations, active workflow version and relevant company.
- Access prerequisites: Confirm sign-in, licensing, worker or hierarchy mappings where used, and access to the required documents and workflow history.
- Recovery arrangements: Identify who can cancel test workflows, restore configuration and remove temporary assignments.
Do not test an accounts-payable clerk’s restrictions while signed in as an administrator. Use the clerk’s actual proposed permissions.
In Dynamics 365, access is built through a hierarchy of roles, duties, privileges and permissions. Roles can inherit other roles, while data-security policies can restrict accessible records. Therefore, include inherited access and organizational scope in the baseline—not just the visible role names. (learn.microsoft.com)
For buyers evaluating a demonstration environment, request these same identities and configuration details. If the vendor cannot provide them, mark the relevant control as not tested, rather than assuming it works.
2. Build a conflict matrix around activities
Use business activities as the starting point, then map them to the ERP’s actual security objects.
The table below is an illustrative policy matrix, not a universal accounting requirement.
| Activity combination | Proposed restriction | Sandbox check |
|---|---|---|
| Maintain vendor bank details + release payments | Separate responsibilities | Bank-detail maintainer cannot authorize release |
| Enter invoice + approve the same invoice | Prevent self-approval | Submitter cannot complete their own approval |
| Prepare payment batch + authorize release | Require independent authorization | Preparer cannot provide the required independent release |
| Administer workflow + approve transactions | Restrict and independently review privileged access | Business approver cannot change approval rules |
| Approve in one company + transact in another | Limit to authorized scope | User cannot approve outside assigned company |
For every row, record the risk owner, permitted exceptions, relevant roles and privileges, affected entities, and expected response.
Distinguish access conflicts from transaction conflicts. A user might legitimately enter some invoices and approve other people’s invoices. The policy may prohibit approving their own transaction without prohibiting both activities altogether. Test the precise rule the business intends.
Microsoft’s segregation-of-duties setup pairs conflicting duties and records risk and mitigation information. Its documentation also warns that creating a rule does not validate existing roles or user assignments; validation is a separate step. (learn.microsoft.com)
Run both configuration review and transaction tests. A clean conflict report is useful evidence, but do not use it as a substitute for proving the required transaction behavior.
3. Test approval thresholds and self-approval explicitly
Translate approval policy into unambiguous conditions before entering test invoices.
Specify:
- Whether the limit applies to a line, document or payment batch.
- Whether the amount includes tax and charges.
- Which currency applies and, where relevant, how conversion is determined.
- Whether a boundary means “less than” or “less than or equal to.”
- Whether multiple approvals are sequential, independent or alternatives.
- What should happen when no eligible approver is found.
Then test just below, exactly at and just above each boundary. Use the smallest relevant currency increment. Include rejection, requested changes and resubmission in the scripts.
Dynamics 365 provides a condition-testing function for approval processes. Use it to check routing conditions, then run the full transaction to verify the resulting assignment and completion behavior. (learn.microsoft.com)
Do not assume self-approval is blocked by default. Microsoft documents a “Disallow approval by submitter” setting whose default is No. Its final-approver option is a separate mechanism. Check the actual configuration and prove the intended outcome with the submitter’s account. (learn.microsoft.com)
Also inspect group completion rules. Dynamics 365 supports different policies, including a single responding approver and majority-based approval. Assigning several people to a step does not, by itself, demonstrate that every person must approve. (learn.microsoft.com)
4. Use a worked invoice-to-payment scenario
The following example uses hypothetical people, amounts and control requirements. It describes expected test outcomes, not verified behavior of any particular ERP.
Assume this policy:
- Avery maintains vendor records but cannot release payments.
- Blake enters invoices but cannot approve their own submissions.
- Casey approves invoices up to and including $10,000.
- Invoices above $10,000 require Casey’s approval followed by Drew’s.
- Emery prepares payments; Finley independently authorizes release.
- Vendor bank-detail changes require independent verification before payment.
Run each action through the normal supported interface and any applicable integration route.
| Test | Action | Expected result under this policy |
|---|---|---|
| V1: permitted vendor work | Avery creates a synthetic vendor | Creation succeeds |
| V2: prohibited combination | Avery attempts payment release | Release is denied |
| I1: boundary approval | Blake submits a $10,000 invoice | Casey can complete invoice approval |
| I2: above boundary | Blake submits a $10,000.01 invoice | Casey’s approval is followed by Drew’s |
| I3: self-approval | Blake attempts to approve their submission | Approval is blocked |
| P1: premature payment | Emery attempts payment processing before required invoice approvals | Processing is blocked at the defined control point |
| P2: independent release | Emery prepares an eligible payment; Finley authorizes it | Release succeeds through the approved test route |
| P3: preparer release | Emery attempts independent release | Authorization is denied |
| V3: changed bank details | Avery changes bank details before release | Payment remains held until required verification |
For I2, retain evidence that Casey’s action left the invoice awaiting Drew—not merely that Casey received a notification.
For V3, inspect which bank details the payment actually uses. Define whether the expected response is a hold, renewed approval or another documented safeguard.
If the ERP cannot enforce a proposed outcome, record a capability gap. Do not quietly rewrite the expected result to match the demonstration. Where the business accepts a manual control, document its owner, evidence and limitations separately.
5. Test delegation, absence and escalation as separate paths
Include delegation in the test plan even when normal approvals work correctly.
Dynamics 365 documents manual reassignment of individual work items and automatic delegation with scope, start and end date/time settings. Its mass-delegation capability is feature-controlled and limited to specified workflow types. Verify availability in the target environment before writing the script. (learn.microsoft.com)
Use these proposed tests:
- Eligible delegate: A designated substitute receives and completes the intended task.
- Ineligible delegate: Attempt delegation to the submitter or another person prohibited by policy.
- Scope restriction: A delegation intended for one workflow does not affect unrelated workflows.
- Time boundaries: Submit new work before, during and after the delegation window.
- Outstanding work: Inspect separately what happens to tasks already delegated when the window ends.
- Escalation: Let a task become overdue and verify the resulting assignee and action.
- No available approver: Remove the expected approver in a controlled test and inspect the exception route.
Do not assume the delegate’s normal approval limit governs a delegated task. Record the observed authority and compare it with the approved policy.
Dynamics 365 approval steps have configurable time limits and escalation behavior. Test the configured overdue path instead of assuming it merely sends a reminder. (learn.microsoft.com)
6. Capture evidence that explains the result
For each test, retain a compact evidence record:
- Test ID, policy requirement and expected outcome.
- Environment, application version and workflow version.
- User identity, effective role assignments and company scope.
- Transaction ID, amount, currency and relevant status.
- Steps performed and actual outcome.
- Workflow assignment, approval, rejection or delegation history.
- Defect reference, corrective change and retest result.
Dynamics 365’s workflow history exposes identifiers for the instance, workflow and document, along with version, status and submission time. Work-item and tracking details provide additional process evidence. Use these records to connect the outcome to the configuration tested. (learn.microsoft.com)
For a prohibited action, capture both the attempted action and the unchanged business state. An error message alone does not establish that no transaction progressed.
Keep workflow evidence distinct from evidence of vendor-data changes, role changes and bank authorization. Request the relevant logs or records separately, and document any logging gaps. Protect exported evidence according to the organization’s access and retention policies.
7. Resolve gaps and set a clear sign-off standard
Before sign-off, check for these common mistakes:
- Testing each role alone: Also test the role combinations users will actually receive.
- Testing only successful transactions: Include denied actions and failed routing.
- Checking only screen access: Exercise supported imports and integrations where they are in scope.
- Stopping at invoice approval: Continue through payment preparation and the defined release boundary.
- Treating every conflict as an automatic block: Review permitted overrides and their reasons.
- Ignoring assignment methods: Validate group-derived access separately where the product’s checks have limitations.
Microsoft documents that conflicting user-role assignments can be allowed through an override requiring a reason. It also notes a limitation in conflict verification for roles assigned through Active Directory Domain groups. Include those cases in the review where applicable. (learn.microsoft.com)
Use a proposed exit standard of: all policy-critical permitted and prohibited tests passed; evidence retained; defects resolved and retested; and any exceptions explicitly accepted by the accountable finance and security owners.
After testing, remove temporary access, restore the approved baseline and verify that live connections remain disabled until authorized cutover. Schedule targeted regression tests after changes to roles, workflows, integrations or organizational hierarchies.
The sign-off should state which controls were tested, in which configuration, and with what limitations. Do not describe a successful sandbox test as a blanket compliance certification.