ERP User Acceptance Testing: Scope, Script, and Run It

What ERP user acceptance testing actually is

ERP user acceptance testing (UAT) is the final test you run before you deploy the solution to production. It is always a manual test, and it is performed by the business users who will actually operate the system, in a dedicated, integrated test environment. Its purpose is not to find every remaining bug — it is to get sign-off and approval from the business stakeholders that the solution meets their needs and is fit to run the operation. In Microsoft's Success by Design framework, UAT happens in the Prepare phase, before the Cutover phase, and it is an explicit prerequisite to reaching the go-live milestone.

The key word is acceptance. UAT is owned by the business, not by the implementation partner or the developers. The people who run it are the order processors, accountants, warehouse leads, and buyer roles who do the work day to day. They run a real-life operation simulation using customer data and the in-scope scenarios for their roles, then confirm that the solution supports their business operations and goals. At the end of a successful UAT, those users should be confident and comfortable using the new solution for their daily tasks — and the final iteration requires the business to sign off and accept the solution before deployment.

What UAT is not matters just as much. It is not a second round of system integration testing, not a place to revisit design decisions, and not a bug hunt for issues the build team should have caught earlier. By the time UAT begins, the solution should already be stable: unit, functional, process, and end-to-end testing should have run, and consultants should have done their functional testing first so the solution is stable before business users ever see it. UAT is the acceptance gate that converts all of that earlier work into a documented business decision to go live.

Where UAT sits in the ERP testing stack

A mature ERP test phase layers several test types, each with a different owner, environment, and purpose. UAT is the last of these layers, and confusing it with the earlier ones is the most common reason a project declares UAT "done" while still carrying real risk into production. Unit testing is done by developers on individual components; functional testing is done by consultants and subject matter experts to confirm configuration matches the design; process testing chains functional tests into a business-process flow under role-based security; and end-to-end testing connects all in-scope processes across integrated systems on a full set of migrated data.

End-to-end testing is the closest cousin to UAT and the one most often conflated with it. The distinction is intent and ownership. End-to-end testing verifies that the entire solution works as a whole and integrates with external systems — it is technical and comprehensive, run mainly by consultants and testers. UAT verifies that the solution works for the business — it is acceptance-focused, run entirely by business users, and it produces the sign-off artifact. End-to-end should require multiple cycles and should not be planned as a single late event, because planning only one cycle leaves little time to react to final fixes.

The table below makes the boundaries explicit. Treat it as a contract during planning: if the wrong test type is being used to justify a go/no-go decision, the decision is built on the wrong evidence.

How to scope UAT so it covers the right risk

UAT scope is defined by business processes, not by features. The right starting point is the list of in-scope end-to-end processes the solution is meant to support — order-to-cash, procure-to-pay, record-to-report, plan-to-produce — and the scenarios and variations within each that real users will encounter. Every UAT scenario should trace back to a business process and a requirement, because that traceability is what lets you report and sign off on readiness with confidence rather than on a feeling that things "mostly worked."

Scope should be proportional to business risk and impact. A low-complexity finance deployment in the private sector needs less testing depth than a high-complexity manufacturing deployment in a regulated industry, and the test plan should reflect that. Within UAT specifically, prioritize the processes that are mission-critical to the operation and the processes that carry the most downstream damage if they fail at go-live — cash receipts, payroll, inventory valuation, tax determination, and the period close. Edge cases and low-frequency scenarios belong in UAT only when they are genuinely business-critical or regulated.

Be explicit about what is out of scope for UAT, and write it down. Anything already covered and signed off in functional or end-to-end testing does not need to be re-proven in UAT; doing so burns scarce business-user time and delays sign-off. New change requests discovered during UAT should be logged as gaps and deferred — they are enhancements to discuss and prioritize, not acceptance criteria for this go-live. A written in-scope and out-of-scope statement, agreed before UAT starts, is the single best defence against UAT scope creep. Build a simple process coverage matrix (process × scenario type × owner × priority) so steering can see at a glance which critical paths still lack a passing script before go-live.

Process coverage matrix: what must pass before sign-off

A coverage matrix turns "we tested a lot" into "we tested the right things." Build it as a grid of critical business processes against scenario types — happy path, exception path, security/negative, integration, and period close — then assign a business owner, a script ID, a priority, and a cycle target. Steering should be able to open one page and see which mission-critical cells are still blank or red.

Start with the processes that move cash, inventory, customers, and compliance. For a typical mid-market Dynamics 365 or Odoo rollout that is enough to structure risk: order-to-cash (quote → order → ship → invoice → cash app), procure-to-pay (PR → PO → receipt → invoice → payment), inventory (receive, issue, transfer, count, valuation), record-to-report (journals, allocations, close, reports), and any industry spine (manufacturing orders, project billing, field service, multi-company intercompany). Add tax determination, credit control, returns, and approval workflows where they exist in scope.

Mark each cell mandatory only when failure would stop operations or create regulatory/financial risk. Everything else is secondary coverage for later cycles or hypercare. The matrix also enforces ownership: the SI can draft scripts and facilitate execution, but the business process owner is accountable for pass/fail and for the signature on that process area. If a cell has no named owner, it will not get honest testing.

How to write ERP UAT test scripts that prove readiness

A UAT test script (test case) is a set of instructions that guides the tester to execute a test and verify the expected outcome. Microsoft's guidance is that a test case should reflect the actual business execution in the system and represent how the user operates the solution. At a minimum, every UAT script must include four elements: the process and requirements the test case covers; the prerequisite or entry criteria needed to run the test (such as data or configuration dependencies); the reproduction steps the tester performs; and the expected outcome or exit criteria used to validate the result. Without all four, a script cannot be executed repeatably or judged pass or fail.

Design scripts for both positive and negative scenarios — what should happen and what should not happen. Positive scripts walk the happy path of a real transaction end to end; negative scripts confirm that the system blocks invalid input, enforces segregation of duties, and rejects unauthorized actions the way production must. Negative testing is where most real go-live surprises hide, because it is the layer that proves role-based security and validation rules actually work under the real security roles users will have in production. Run every script under the correct, assigned role — never under a blanket administrator account, which hides the security boundaries users will hit on day one.

Write scripts in business language with exact test data — not vague prompts. Prefer "enter customer Contoso Wholesale, PO 45001234, line amount 1,250.00 EUR" over "enter a valid sales order." Each step should be atomic (one action, one expected result), and every script should leave room for actual result, pass/fail, evidence (screenshot or recording), tester name, role used, and date. That evidence pack is what makes sign-off reviewable after the meeting rather than trapped in memory. Use real, migrated data, not demo or synthetic records: end-to-end and UAT testing require a full set of migrated data from the legacy system, which has different data patterns than demo or test data; testing against dummy data is one of the classic ways a solution looks ready in the sandbox and then breaks in production.

Capture scripts with the platform's tooling so they are repeatable and traceable: for Dynamics 365 finance and operations apps, Task Recorder records steps that can be turned into Azure DevOps test cases and, later, into automated regression tests; for Business Central and Odoo, document scripts in a shared test-management tool linked to the process flows. Whatever the tool, the discipline is the same — each script is tied to a requirement, owned by a role, and judged against a concrete expected result, not a subjective impression. The field structure below is what a usable ERP UAT script looks like when you open it on day one of a cycle.

Running UAT: cycles, environments, and the people in the room

UAT runs in cycles, and each cycle is a mini go-live for the scope it covers. A test cycle is a comprehensive testing event over a specific scope and version of the solution — sometimes called a conference room pilot, a testing iteration, or a testing milestone — and treating it as a rehearsal of the business operation is what makes UAT meaningful rather than ceremonial. Plan for multiple cycles rather than a single UAT event at the end of the build, because a single late cycle leaves almost no time to react to the defects it uncovers.

Before any tester touches the system, the environment and the people must be ready. Run UAT in a dedicated, integrated test environment that matches production as closely as possible — for Dynamics 365 finance and operations apps, that means a Tier-2 or higher sandbox, never a Tier-1 environment; for Business Central, a sandbox copy with documented precautions; for Odoo, an Odoo.sh staging branch, which is a neutralized duplicate of production data with scheduled actions off and payments in test mode. Load the latest solution version plus migrated customer data, and make sure the integrations to external systems (banking, e-commerce, payroll, EDI) are connected so end-to-end flows are exercised for real. Never run regular testing in the production environment — production is reserved for a mock cutover test.

Then prepare the testers. The business users who do UAT should be trained on the solution and the new processes before they start testing, so their findings reflect the system rather than unfamiliarity with it. For each cycle, communicate the plan in writing: the objectives, the scope (which processes, requirements, and scripts are covered), the schedule, the roles and responsibilities, the bug-resolution process, the progress-tracking method, and the test sequence — especially the order and dependencies between scripts for process and end-to-end testing. Clear expectations keep a cycle focused on its objective instead of drifting into redesign or scope debate.

Do not stop at daily transactions. Practitioners consistently report that the first month-end close — not the order entry screen — is what keeps ERP teams awake before go-live. Daily flows get exercised constantly during UAT; period close, accruals, open-item volumes, and posting-date distribution usually run once and only against thin data unless you deliberately generate a full period of realistic history. Schedule at least one full period-close rehearsal (ideally two) against production-scale migrated data inside UAT, with finance owners timing the window the way they will after go-live. If the close only "works" on a handful of journals, you have not tested the close.

Who does what — and a sample two-week mid-market UAT calendar

UAT fails when roles blur. The system integrator (SI) prepares environments, drafts and maintains scripts, facilitates sessions, logs defects, and drives retest logistics. The customer business owns scope, provides testers, runs the scripts under real roles, judges pass/fail against acceptance criteria, and signs off. Steering decides residual risk and go/no-go. QA/test leads keep the register clean; architects own design-level issues; change management protects tester time and training. Never let the SI "pass" UAT for the customer — that invalidates the acceptance gate.

For many SMEs with a focused first release (core finance + one or two operational pillars), a two-week intensive UAT block works when it sits after stable SIT and before mock cutover — ideally as the last of two or three cycles, not the only one. Compressing everything into ten business days only works if scripts, data packs, roles, and triage cadences are ready on day 0. Larger or regulated programs need longer calendars; use the pattern below as a skeleton, not a universal law.

Daily rhythm matters more than the pretty Gantt. Run a short morning stand-up (blocked scripts, environment, data), afternoon defect triage with severity assignment, and a visible dashboard of critical-script pass rate. Leave explicit retest slots after each fix batch so green cells stay green. Reserve the final two days for period-close rehearsal, residual regression on fixed areas, and formal sign-off meetings per process owner — not for discovering brand-new scope.

Handling defects: bugs, gaps, and ownership

Every defect found in UAT must be documented, tracked, and routed to an owner — never left to memory or a hallway conversation. Track defects in a centralized repository that the whole project team can see, such as Azure DevOps, which integrates into the application lifecycle so bugs are visible to the people who must fix them. A useful defect record includes the test case and step reference, clear reproduction steps, and rich evidence such as screenshots or recordings, so the resolver can reproduce and fix the issue quickly rather than chasing the reporter for detail.

Classify severity before priority so triage stays honest. A practical ERP scale: Severity 1 (blocker) — cannot complete a critical process or data integrity is at risk; Severity 2 (critical) — major business function fails with no acceptable workaround; Severity 3 (major) — significant issue with a temporary workaround; Severity 4 (minor) — cosmetic or low-impact annoyance. Priority (how soon you fix it) can differ from severity when a workaround exists, but exit criteria should be written against severity so steering cannot redefine "critical" mid-cycle. Common cutover exit rules used by mature programs: no open Sev-1 or Sev-2 defects; Sev-3 and Sev-4 only if each has an owner, workaround, and target fix date after go-live.

The most important triage discipline is distinguishing bugs from gaps. A bug is a defect that needs to be fixed — the system does not behave as the accepted design specifies. A gap is a difference between expected and actual behaviour caused by a missing or incomplete feature, a change in requirements, or a new improvement idea; gaps are enhancements to discuss and prioritize, not acceptance blockers for this go-live. When a tester reports a gap, classify it correctly and funnel it to the project manager and stakeholders rather than letting it inflate the UAT defect count or block sign-off. Stick to the test case when reporting: if the issue is outside the script's scope, it is almost certainly a gap.

Route outcomes to the right owner by type. Bugs go to developers; configuration issues go to consultants; gaps go to project managers for stakeholder discussion; standard product issues go to the vendor's support channel; conceptual design issues go to the architects; and process improvements go to business subject matter experts. UAT outcomes specifically are typically owned by the customer steering group or lead SMEs. Crucially, any configuration change made to fix an issue can invalidate earlier-passing test cases, so treat a fix like a production change and run regression testing on the affected area before accepting it. As you near go-live, weigh the value of a late fix against the risk of not having time to regression-test it properly — sometimes deferring a non-critical fix is safer than rushing a change you cannot fully retest.

UAT exit criteria and earning business sign-off

Sign-off is the entire point of UAT, so define what earns it before the cycle starts, not during it. The final UAT iteration should confirm that the solution meets business requirements, performs acceptably, and works as expected across the critical end-to-end processes, and that the business stakeholders accept it. Exit criteria are concrete and measurable: all in-scope critical scripts executed under the correct roles; all severity-one and severity-two defects resolved or formally accepted with an owner and a date; migrated data reconciled against the legacy balances for the processes in scope; and a named business owner signing the acceptance document for each process area.

Entry criteria protect the cycle from becoming a disguised build phase. Do not open UAT until functional and end-to-end testing are complete (or explicitly residual-risk accepted), the release candidate is frozen for the cycle, the environment matches the agreed tier/sandbox rules, migrated data is loaded and spot-reconciled, integrations needed for in-scope scripts are connected, tester accounts exist with production-like roles, scripts and data packs are published, and business users have completed role training. Starting UAT with open Sev-1s from SIT almost guarantees a failed first cycle and burned goodwill.

Understand what sign-off does and does not mean. Signing off does not mean the solution is perfect or bug-free; it means the solution is good enough to operate the business safely and efficiently, with any remaining minor issues tracked for later fix without introducing unnecessary risk. This framing matters because it keeps UAT honest: a project that demands zero open defects before sign-off will either never go live or will pressure testers into not reporting issues, while a project that signs off with no criteria at all has accepted nothing. The middle ground — critical defects closed or formally accepted, minor defects logged with owners — is what a defensible acceptance decision looks like. Keep an evidence pack: plan, coverage matrix, executed scripts with results, defect register with dispositions, retest logs, data reconciliation samples, and written process-area signatures.

Sign-off feeds directly into the go/no-go decision and, for Dynamics 365 finance and operations apps, into the FastTrack Go-live Readiness Review, which confirms UAT completion and documented business sign-off among its prerequisites. Once the business accepts the solution, the remaining gates are operational: a rehearsed cutover runbook, a go/no-go call against pre-agreed criteria, and a hypercare plan. Those deployment mechanics — mock cutover, go/no-go, rollback triggers, and hypercare — belong to the go-live checklist, which is the natural next step after a clean UAT sign-off.

The UAT mistakes that turn go-live into a gamble

Most UAT failures are predictable and avoidable. The first is rubber-stamping — a UAT cycle with no real criteria that exists only to tick a box on the way to a date. If sign-off cannot point to a set of executed scripts, resolved critical defects, and a named business owner per area, it is not acceptance; it is a deadline. Proof of testing should be reviewable after the meeting: expected transitions, observed results, and exceptions attached to the decision — not "someone clicked through it." The second is running UAT under administrator rights or on demo data, which hides the exact problems — security boundaries, real data patterns, integration failures — that surface only in production. Microsoft is explicit that testing must use migrated data under the correct security roles, and that one common cause of failure is poor involvement or feedback from the business testers.

The third mistake is the single late UAT cycle. A solution that has never been tested end-to-end on integrated data until a few weeks before go-live gives the team almost no runway to fix what it finds, and every fix then risks invalidating the tests that passed. Plan multiple cycles earlier in the Prepare phase so the final iteration is a confirmation, not a discovery exercise. The fourth is scope creep during UAT — letting newly requested features become acceptance criteria, which both delays go-live and changes what the business is being asked to accept. Lock scope, log new requests as gaps, and defer them to a post-go-live backlog.

The fifth and most damaging is weak business participation. UAT exists to win the confidence and acceptance of the people who will run the system; if those people are not in the room, testing it, the acceptance is hollow and adoption suffers after go-live. Allocate real time for business users to test, train them first, and make their sign-off the authoritative input to the go/no-go decision. A sixth failure mode is skipping period close, multi-company, tax, and integration-edge scripts because "daily works" — then discovering the first real month-end in production. When these patterns are avoided, UAT stops being a formality and becomes the evidence that makes cutover a reasoned decision — which is the whole point of the implementation phases that lead up to it.

UAT mechanics for Dynamics 365 and Odoo

The UAT method is platform-agnostic, but the mechanics differ. For Microsoft Dynamics 365 finance and operations apps, UAT and performance testing must run in a Tier-2 or higher sandbox environment, never Tier-1, because the performance and behaviour characteristics of a Tier-1 environment do not represent production. Capture scripts with Task Recorder, store them as test cases in Azure DevOps, and use the same recorded steps later as the foundation for automated regression testing with tools such as the Regression Suite Automation Tool. UAT completion and documented business sign-off are prerequisites the FastTrack Go-live Readiness Review checks before production is provisioned. Microsoft has been modernizing that review toward a faster, AI-assisted flow on the Implementation Portal while keeping Success by Design principles — plan UAT evidence so it maps cleanly to the readiness questionnaire rather than scrambling for screenshots the week of review.

For Dynamics 365 Business Central, UAT is typically run in a sandbox copy of the production environment created through the Business Central Administration Center, with documented precautions — job queues stopped, integrations cleared, and outbound HTTP blocked during setup so test activity does not leak into live systems. Business Central implementations are partner-led and do not require an equivalent mandatory Microsoft portal review, but the UAT discipline is the same: migrated data, real roles, business sign-off.

For Odoo, UAT runs against an Odoo.sh staging branch, which is a neutralized duplicate of the latest production data — emails caught in a mail catcher, scheduled actions off unless explicitly triggered, and payments and in-app purchases in test mode — making it the most realistic place to validate business processes before cutover. Important 2025–2026 operational detail: Odoo.sh staging databases are intentionally ephemeral (commonly auto-deleted after about 30 days after rebuild). They are built for short validation loops, not multi-month UAT warehouses. If your UAT calendar spans longer than a staging lifetime, plan rebuild-and-restore cycles, external dump backups of test data packs, or a dedicated long-lived UAT project/environment so scripts and period-close data do not vanish mid-cycle. Build UAT scripts against the in-scope apps and the configured flows, link them to the imported master and configuration data so dependencies resolve, and have business users run the core order-to-cash, procure-to-pay, and accounting-close flows end to end before any sign-off. Regardless of platform, the rule is identical: integrated environment, migrated data, real roles, business users, documented acceptance.

How Flectic runs UAT for SMEs

Flectic is a platform-neutral implementation partner for Microsoft Dynamics 365 and Odoo, focused on small and midsize enterprises. We treat UAT as the acceptance gate it is meant to be, not a box to tick. Our delivery model is designed to run up to 3x faster than a traditional ERP implementation, using AI-assisted test-script generation, scenario drafting, and defect triage to compress UAT preparation without cutting the steps that protect a clean sign-off.

On every engagement we scope UAT to the critical end-to-end processes with a coverage matrix, write scripts with all required fields and traceability to requirements, run them under real roles on migrated data in the right environment (Tier-2+ sandbox for Dynamics 365 finance and operations apps, Business Central sandbox, or Odoo.sh staging with lifetime planning), include period-close rehearsal, and triage defects by severity and type with named owners. We define entry/exit criteria up front and pursue documented business sign-off per process area before we ever let a project move to cutover. The platform choice — Dynamics 365 Business Central, Dynamics 365 finance and operations apps, or Odoo — follows your headcount, complexity, and roadmap, not our preference.

If you are approaching UAT and want a second pair of eyes on your test plan, coverage matrix, and scripts, or you are starting fresh and want a delivery model that treats acceptance as the gate it is, book an ERP Readiness Call. We will review your UAT scope, environment, calendar, and exit criteria and flag where your sign-off is at risk.

Frequently asked questions