Quick answer
ERP user acceptance testing (UAT) should establish whether business users can complete agreed workflows and obtain the required results. Connect each requirement to a role-based scenario, specify expected outcomes before execution, retain evidence, and require business-owner acceptance. Set exit criteria before testing—not when the launch date arrives. UAT is one readiness check, not a substitute for integration, performance, security or migration testing. (learn.microsoft.com)
The practical framework below is intended for finance, operations and IT teams preparing an ERP rollout. It includes a hypothetical purchase-order receipt and supplier-invoice test pack. The suggested thresholds are project-policy examples, not industry benchmarks.
1. Define what UAT must prove
Start with business outcomes rather than a list of screens. “The purchase order page opens” is not the same acceptance question as “an authorized buyer can order stock, receiving can record a partial delivery, and accounts payable can identify an invoice for unreceived goods.”
Microsoft’s testing guidance distinguishes UAT—testing from the users’ perspective—from integration, performance, security and migration testing. Keep those disciplines coordinated, but do not assume a successful business walkthrough proves them all. (learn.microsoft.com)
Before inviting testers, use these proposed entry checks:
- Identify the release, configuration and business processes under test.
- Make required integrations available, or document any substitutes and their limitations.
- Prepare test users with the intended operational roles.
- Agree on test data, opening balances and expected results.
- Resolve defects that would prevent meaningful execution.
- Assign business owners and approve the test plan.
Record environment changes during the cycle. If a configuration change affects a tested workflow, identify which results need to be repeated. Microsoft recommends aligning test cycles with solution versions and tracking outcomes and ownership. (learn.microsoft.com)
2. Trace requirements to scenarios and evidence
Create a small traceability register before writing detailed scripts. Its purpose is to show which business requirements have supporting test evidence.
Use this proposed structure:
| Requirement ID | Business requirement | Scenario IDs | Acceptance owner |
|---|---|---|---|
| PUR-01 | Only authorized roles approve purchases | UAT-P01, UAT-P06 | Procurement lead |
| INV-01 | Partial receipts update the correct stock location | UAT-P02 | Warehouse lead |
| AP-01 | Quantity mismatches follow the approved exception process | UAT-P03, UAT-P04 | AP lead |
| FIN-01 | Receipt and invoice postings reconcile | UAT-P02, UAT-P05 | Controller |
Add columns for risk, execution status, evidence and unresolved defects. Microsoft’s strategy guidance calls for testing against business requirements and tracking results, ownership and issues for each case. (learn.microsoft.com)
For this register, distinguish:
- Coverage: Does the requirement have an approved scenario?
- Execution: Has someone run that scenario?
- Acceptance: Did its actual results meet the expected results?
Do not mark a requirement accepted merely because a script exists. Where several cases support one requirement, define whether all must pass.
3. Write scenarios around roles, outcomes and exceptions
A useful scenario describes a business situation, its starting conditions, the actions users take and the results they must verify. Microsoft recommends test cases that reflect actual business execution and include expected outcomes. (learn.microsoft.com)
Use this reusable template:
| Field | What to record |
|---|---|
| Identity | Scenario ID, requirement IDs and risk |
| Starting point | Environment, release, configuration and prerequisites |
| People | Tester and operational role for each step |
| Data | Supplier, item, location, quantities and document references |
| Actions | Numbered steps, including handoffs |
| Expected results | Status, quantities, approvals, accounting and reports |
| Evidence | Actual results, screenshots, exports and document IDs |
| Decision | Pass/fail/blocked, defect reference and reviewer |
Write expected results before execution. Replace “invoice processes correctly” with a check such as: “The AP clerk cannot post the mismatched invoice without the required exception approval.”
Include ordinary and exception paths. For purchasing, consider partial delivery, missing receipt, price variance, rejected approval, correction and unauthorized access. Select cases according to business risk rather than giving every screen equal attention. (learn.microsoft.com)
Run handoffs with the intended roles. In this framework, a workflow completed only through an administrator account does not satisfy a case intended for a buyer, receiver or AP clerk.
4. Prepare synthetic data and approved accounting expectations
For this test pack, create synthetic records dedicated to UAT:
- Supplier:
UAT-SUP-001 - Stock item:
UAT-ITEM-001 - Warehouse:
UAT-WH-01 - Opening stock: zero
- Order: 100 units at $10 each
- First delivery: 80 units
- Initial supplier invoice: 100 units at $10 each
These are illustrative inputs, not customer records or observed results. Exclude tax, freight, discounts, currency conversion and other stock movements from this simplified case. Add separate cases for those features when they are in scope.
Use a nonproduction environment, dummy contact details and isolated external connections. Have qualified administrators check that test activity cannot send real supplier messages or payment instructions.
Before execution, ask finance to approve the expected posting map. Do not assume every ERP records receipt accounting identically. Microsoft documents settings controlling physical inventory posting and receipt accruals, so expected ledger results must reflect the configured solution. (learn.microsoft.com)
For the worked example, assume receipt accrual accounting is enabled and the approved economic effect is:
| Event | Illustrative expected effect |
|---|---|
| Receive 80 units | Inventory increases by $800; received-not-invoiced liability increases by $800 |
| Post a corrected invoice for 80 units | Receipt liability clears by $800; supplier payable increases by $800 |
| Invoice posting | Physical stock remains 80 units |
Actual vouchers may use additional clearing or offset accounts. Microsoft describes purchase accrual being reversed and transferred to accounts payable when the purchase is invoiced. Finance should translate that behavior into the project’s approved accounts and dimensions. (learn.microsoft.com)
5. Execute the purchase-to-invoice test pack
The following pack is hypothetical and vendor-neutral. It assumes an approved requirement that an ordinary AP clerk cannot post an invoice with an unresolved quantity mismatch.
Product reference: Microsoft Dynamics 365 Finance documentation illustrates three-way matching by comparing invoice prices with purchase-order prices and invoice quantities with matched product receipts. This supports the scenario design; it does not establish identical behavior in every ERP. (learn.microsoft.com)
| Case | Role and action | Expected result and evidence |
|---|---|---|
| UAT-P01: Approve order | Buyer creates the 100-unit order; designated approver approves it | Order value is $1,000; approval follows the agreed policy. Retain order ID and approval history. |
| UAT-P02: Receive partially | Receiver records 80 units against the order | Stock increases from 0 to 80 at the intended location; 20 units remain outstanding. Retain receipt ID, stock inquiry and ledger evidence. |
| UAT-P03: Enter mismatch | AP clerk enters an invoice for 100 units against the 80-unit receipt | Matching identifies the discrepancy. Under the assumed policy, ordinary posting cannot complete without authorized exception approval. |
| UAT-P04: Resolve mismatch | Procurement investigates; AP records the synthetic supplier’s corrected 80-unit invoice | Match passes for 80 units at $10. Preserve the original discrepancy evidence and follow the documented correction process. |
| UAT-P05: Post and reconcile | AP posts the corrected invoice; finance reviews it | Payable is $800, receipt accrual is cleared, stock remains 80, and 20 units remain outstanding. |
| UAT-P06: Deny unauthorized action | Receiver attempts purchase approval and invoice posting | Both actions are denied under the assumed role design. Retain evidence of denial. |
The mismatch calculation is:
100 invoiced − 80 received = 20 unmatched units
20 × $10 = $200 of unmatched invoice value
A matching warning alone is not evidence that posting is prevented. Dynamics 365 Finance documents configurable treatment of matching discrepancies, including approval requirements. Verify the actual posting outcome against the approved requirement. (learn.microsoft.com)
After UAT-P05, reconcile document quantities, inventory, supplier balance and general-ledger postings. Check the supplier, item, warehouse, posting date, account and financial dimensions—not just the final invoice total.
For a separate completion case, receive the remaining 20 units and invoice $200. Under the same simplified assumptions, the final totals should be 100 units received and $1,000 invoiced, with no outstanding receipt accrual for this order.
6. Triage defects and retest the affected workflow
For this framework, log each unexpected result with:
- Scenario and requirement IDs.
- Release, role and test-data references.
- Reproduction steps.
- Expected and actual results.
- Business impact and evidence.
- Owner, severity, priority and target resolution.
During triage, distinguish a software defect from configuration, data, permission, training or requirement issues. Record the resolution rather than closing an issue as “user error” without explaining what must change.
Adopt explicit severity definitions. Suggested examples are:
- Critical: Material data corruption or failure of an essential control.
- High: Essential workflow cannot complete with no approved practical workaround.
- Medium/low: Limited impact that the accountable owner can assess and potentially accept.
Set fix priority separately from severity. A lower-severity issue may still need early attention if it blocks many tests.
After a fix, rerun the failed case and relevant connected cases. For a matching change, that may include the valid invoice, partial receipt, mismatch and unauthorized-role tests. Microsoft’s test guidance treats regression testing as checking that changes have not adversely affected existing functionality. (learn.microsoft.com)
7. Set measurable exit criteria and assign sign-off
Agree on thresholds before execution. The following are proposed criteria for this six-case pack—not universal ERP standards:
| Gate | Proposed measurable criterion |
|---|---|
| Traceability | All five listed requirements have linked cases and acceptance evidence |
| Execution | All six cases executed; none blocked or unrun |
| Results | All six cases pass on the release proposed for deployment |
| Defects | Zero unresolved critical or high defects |
| Reconciliation | Exact quantity and dollar agreement for the simplified example |
| Residual risk | Every remaining issue has an owner, impact assessment, workaround where applicable, target date and written acceptance |
| Approval | Procurement, warehouse, AP and finance owners sign their relevant results |
Keep failed, blocked and unrun cases visible. If reporting a pass rate, define its denominator; do not silently remove unfinished cases.
Assign sign-off responsibilities explicitly:
- Functional owners: Accept business outcomes and residual operational risk.
- Controller or finance owner: Accept accounting and reconciliation results.
- IT/security owner: Confirm technical and access-control evidence within their remit.
- Test lead: Confirm evidence completeness and status accuracy.
- Executive sponsor or designated decision body: Make the final go/no-go decision.
UAT approval should feed into a wider readiness review. Microsoft’s go-live checklist also covers integration and performance testing, migration validation, cutover, external dependencies, training and operational support. Passing this purchase-to-invoice pack is not approval for the whole ERP deployment. (learn.microsoft.com)
8. Check for weak evidence before accepting the release
Use these final review questions:
- Did users verify outcomes, or only capture screens? Require quantities, document references, balances and approval evidence.
- Did the normal path dominate testing? Confirm that selected exception and correction paths were executed.
- Were operational roles used? Repeat administrator-only results with the intended users.
- Was inventory counted twice in expectations? In this example, posting the invoice must not add another 80 physical units.
- Were warnings mistaken for controls? Check whether unauthorized posting actually remained possible.
- Did the release change after testing? Identify affected cases and rerun them.
- Does sign-off identify what was accepted? Record scope, release, evidence, unresolved issues, approvers and decision date.
Use these checks alongside the project’s approved test strategy, not instead of it. Microsoft’s guidance emphasizes defined scope, entry and exit criteria, tracked results and business acceptance—the foundations for a defensible release decision. (learn.microsoft.com)