D365ConsultantDivision of Sataware
D365ConsultantDivision of Sataware
Testing before sign-off

User acceptance testing for Business Central, run so that sign-off actually means something.

User acceptance testing for Business Central is the stage where the people who will use the system every day prove it handles their real work, before anyone agrees to go live. It is not the consultant checking their own setup, and it is not a polished demo. Done properly, it finds the gaps in configuration, permissions, reports and migrated data while they are still cheap to fix. Done as a formality, the same gaps appear during the first month end, when fixing them is slow and public.

Sandbox
where testing happens, never production
Key users
the people who run the scripts
Written sign-off
per process, not one signature
Hands typing on a laptop keyboard on a white desk

Who owns which part of user acceptance testing

Runs the tests

Key users

The staff who will process the transactions after go-live. They follow scripts, record what happened, and say plainly when something would slow them down.

  • โœ“Execute scripts in the sandbox
  • โœ“Log defects with screenshots
  • โœ“Retest fixes
Decides

Process owners

The controller, warehouse manager or sales lead who is accountable for a process. They decide whether a defect blocks go-live and sign off their area.

  • โœ“Approve the scripts
  • โœ“Judge severity
  • โœ“Sign off their process
Fixes

Implementation consultants

Consultants prepare the environment, explain expected behavior, triage defects and correct setup or code. However, they should not be the ones marking tests as passed.

  • โœ“Load test data
  • โœ“Triage and fix
  • โœ“Explain standard behavior
Unblocks

Project sponsor

Usually the CFO or owner. The sponsor protects time for testers, settles disputes between departments and makes the final go or no-go call.

  • โœ“Free up tester time
  • โœ“Resolve disputes
  • โœ“Make the final call

Business Central testing scripts built from last month's transactions

Nobody should invent the best test scripts. Instead, take a recent month and pull real documents. Think of a sales order with a partial shipment, a customer who pays short, and a purchase invoice that does not match its receipt. Add a credit memo, an intercompany charge and an inventory adjustment after a cycle count. Each becomes a script that says what to enter, what the tester should expect to see, and which report or ledger proves the result.

Scripts should follow a process end to end rather than testing one screen at a time. Order to cash runs from quote through shipment, invoice, payment and the customer statement. Procure to pay runs from requisition to payment and the vendor aging. Record to report finishes with a trial balance and the financial statements your board actually reads. Testing whole chains catches the handoff problems that single-screen checks miss.

Two details separate useful testing from theater. First, testers must log in with the permission sets they will have in production, not an administrator account. Otherwise you will discover on day one that the receiving clerk cannot post a receipt. Second, testing should run on migrated data that you load the same way you will at cutover. That way, the balances, open items and item cards under test are the real ones.

One acceptance testing cycle in Business Central

  1. 1

    Prepare the environment

    Create a sandbox from the current configuration, load the latest data migration, and set up each tester with their production permission sets.

  2. 2

    Walk testers through the scripts

    A short session per department explains the scripts, where to log results and how to describe a defect so someone else can reproduce it.

  3. 3

    Execute and record

    Testers run every script, mark each step passed or failed, and attach a screenshot and the document number for anything that went wrong.

  4. 4

    Triage daily

    Consultant and process owners meet briefly to agree severity for new defects, separate real faults from training gaps, and assign fixes.

  5. 5

    Retest and regress

    The person who raised each fixed item retests it. Then the team reruns a small set of core scripts to make sure a fix did not break something else.

  6. 6

    Sign off by process

    Each process owner signs their area and lists any open low-severity items. So the sponsor can see exactly what the business is accepting.

User acceptance testing severity levels and what they mean for go-live

Severity
Example
Effect on go-live
Critical
Invoices post to the wrong revenue account, or a warehouse cannot ship
Blocks go-live until fixed and retested
High
A key report shows wrong totals, or a common exception needs a workaround
Blocks go-live unless a written workaround is agreed by the process owner
Medium
An extra click in a daily task, or a field in the wrong place on a document
Can go live with a dated fix plan
Low
Cosmetic layout issues, wording on a form
Logged for after go-live
Training gap
The system behaves correctly but the tester expected the old way
Not a defect; added to training material

Habits that quietly ruin user acceptance testing

  • โœ“Testing with administrator rights, so permission problems stay hidden
  • โœ“Letting the consultant who built the setup mark tests as passed
  • โœ“Using a handful of tidy demo records instead of migrated data
  • โœ“Skipping the month-end steps because they feel far away
  • โœ“Squeezing testing into spare minutes while testers do their full day jobs
  • โœ“Treating every complaint as a defect instead of separating training gaps

User acceptance testing for Business Central: who, where and how often

Who should do user acceptance testing on Business Central?

The people who will do the work after go-live should run the tests, with process owners deciding what passes. Consultants prepare the environment and fix what testers find, but they are too close to the setup to judge it. A tester who processes receipts every day will spot problems a consultant never would. The sponsor's role is to protect their time.

Should we test in production or in a sandbox?

Always test in a sandbox environment, never in the production company you will go live on. Business Central online lets an administrator create sandboxes, including copies of production, from the admin center. Testing in a sandbox means you can reload data, repeat scripts and break things safely. The production environment should only receive the final, signed-off configuration and the cutover data.

How many test cycles do we need?

Plan for at least two, because the first cycle always finds issues whose fixes need retesting. The first pass exposes setup gaps and data problems; the second confirms the fixes and runs the full chains on a fresh data load. Complex operations, heavy integrations or poor first results may justify a third. The scope we write at the start sets the plan for your project.

Scope changes, integrations and reports during testing

What if testers find problems nobody asked for in the requirements?

Log them anyway, then decide deliberately whether each one is a gap, a change or a training point. Some are genuine misses that you must fix before go-live. Others are new wishes that can wait for a later phase without hurting operations. Keeping them visible, with a decision against each, stops them turning into arguments after the system is live.

Does acceptance testing cover integrations and reports?

Yes, and they are often where the serious problems hide. Test every integration with real volumes and at least one deliberate failure. Then you see how errors surface and who gets told. Tie reports and financial statements back to ledger totals, rather than just opening them for a glance. If the board pack will come from Business Central, test the board pack.

Talk to us about your project.

Tell us what you run today and what has to change. A senior consultant replies with a written next step.

Get started

Start with a scoping conversation.

Thirty minutes with a senior consultant - not a sales call. We look at how you run today, tell you plainly whether Business Central is the right fit, and give you an honest sense of scope, cost and timeline before you commit to anything.

What happens next
1
We review your enquiry
A consultant reads it before the call - no discovery questionnaire to fill in.
2
30-minute scoping call
Your processes, your current systems, and the gaps that matter most.
3
Written summary & estimate
Indicative phases, licence counts and a cost range, in writing within three days.
Reply within one business day
NDA signed before discovery on request
No obligation, no cost for the scoping call
Microsoft-certified consultants only
Request your scoping call
Four fields. A consultant replies within one business day.
No cost
Your details stay with our consulting team - never shared, never added to a mailing list.