UAT Testing for Business Central: A Practical Guide for Implementation Teams

If you've been through a Dynamics 365 Business Central implementation, you know the pattern. The consultants configure the system, data gets migrated, integrations are built, and then — often with alarmingly little runway — someone announces it's time for UAT. What follows is usually a scramble: hastily written test scripts, confused business users, and a sign-off process held together by email threads and good intentions.

It doesn't have to be this way. This guide is for implementation teams — whether you're a partner delivering Business Central projects or a client-side project manager trying to get your organisation ready for go-live. It covers what to test, how to structure your test plan, the mistakes that trip up nearly every BC project, and how to get meaningful sign-off without the chaos.

1. Why Business Central UAT Is Different from Generic Software Testing

Business Central is not a standalone application. It's an integrated ERP platform where finance, purchasing, sales, inventory, and potentially manufacturing and warehousing all share the same data and posting logic. This creates a testing challenge that generic UAT approaches simply don't address. The key ERP risks in 2026 — from data migration failures to rushed go-lives — apply to BC implementations just as much as any other platform.

Here's what makes BC testing fundamentally different:

• Multi-module dependencies are the norm — a single sales order touches inventory, general ledger, VAT, dimensions, and potentially warehouse management. Testing the sales order in isolation tells you almost nothing about whether it actually works
• Posted entries are immutable — unlike many systems, once a transaction is posted in BC, it cannot be edited or deleted. Errors in posted entries require correcting entries, which means your testers need to understand the posting logic, not just the data entry screens
• Number series, dimensions, and posting groups drive everything — these configuration elements control how transactions behave across the entire system. A misconfigured posting group won't throw an error — it will silently post to the wrong GL account
• Data migration validation is critical — migrated chart of accounts, customer and vendor master data, item records, and opening balances all need to be validated inside real transactions, not just checked against row counts
• Your testers are often not technical — the people who need to validate Business Central are accounts payable clerks, warehouse operatives, and finance managers. They know their processes inside out, but they're not software testers. Your test cases need to be written in their language

2. What to Test in a Business Central Implementation

The biggest mistake in BC UAT is testing features rather than business processes. Your users don't care whether the "Post" button works — they care whether they can complete a month-end close, process a supplier payment run, or fulfil a customer order from pick to dispatch. Here's what you actually need to cover, organised by area.

Finance

Finance is the backbone of every BC implementation. If the GL is wrong, everything is wrong.

• General ledger posting — post journal entries with dimensions and validate they land in the correct accounts. Check that dimension combinations are enforced correctly
• Accounts payable — full cycle from purchase invoice entry through approval (if using approval workflows), posting, and payment. Test partial payments, credit memos, and vendor ledger entries
• Accounts receivable — sales invoice posting, customer payments, application of payments to invoices, and aged debtor reporting. Test cash receipt journals and direct debit processing if applicable
• Bank reconciliation — import bank statements, run automatic matching, and complete manual matching. Validate that reconciled entries post correctly and the bank account ledger balances
• Fixed assets — acquisition, depreciation runs, disposal, and reclassification. Validate that depreciation books post to the correct GL accounts
• VAT and tax reporting — ensure VAT posting groups are configured correctly and that the VAT return report produces accurate figures. This is non-negotiable for go-live
• Month-end and year-end close — run the close income statement batch job, validate retained earnings, and confirm that the new fiscal year opens correctly with the right number series

Supply Chain

Supply chain testing needs to follow the physical flow of goods, not the menu structure of BC.

• Purchase orders — create, approve, receive, and invoice. Test partial receipts, over-receipts (if allowed), and the impact on inventory valuation
• Sales orders — full order-to-cash cycle including order entry, availability checks, shipment, and invoicing. Test back orders, partial shipments, and returns
• Warehouse management — if using directed put-away and pick, test the full warehouse flow: receive, put-away, pick, and ship. Validate bin contents and warehouse entries reconcile with item ledger entries
• Inventory adjustments and transfers — physical inventory journals, item reclassification, and transfer orders between locations. Validate inventory valuation after each operation
• Item costing — if using average, FIFO, or standard costing, validate that cost calculations are correct after purchase, sale, and adjustment transactions. Run the adjust cost batch job and verify the results

Manufacturing (if applicable)

• Production orders — create from sales demand or planning worksheet, release, post consumption and output, and finish. Validate that costs roll up correctly
• BOMs and routing — ensure production BOMs and routings produce the correct component consumption and capacity entries
• Planning worksheets — run MRP/MPS and validate that the suggested actions (purchase orders, production orders, transfer orders) make sense against actual demand

Integrations and Extensions

• Third-party integrations — test data flow in both directions. If BC integrates with a CRM, e-commerce platform, or payroll system, validate that records sync correctly and that error handling works when the external system is unavailable
• Custom AL extensions — any bespoke functionality built in AL code must be tested within the business process it supports, not in isolation. Pay particular attention to extensions that modify posting behaviour or add validation rules
• Power Automate flows — if approval workflows or notifications use Power Automate, test the full flow including edge cases like delegation, timeout, and rejection

Data Migration

• Master data validation — don't just count records. Post transactions against migrated customers, vendors, items, and GL accounts to confirm they behave correctly
• Opening balances — validate that migrated opening balances in the GL, customer ledger, vendor ledger, and bank accounts reconcile to the legacy system's closing balances
• Historical data — if historical transactions have been migrated (for reporting or audit purposes), validate that they appear correctly in the relevant ledger entries and that reports produce accurate results

3. How to Structure Your Business Central Test Plan

A well-structured test plan is the difference between a controlled UAT process and a chaotic free-for-all. Here's how to approach it for a BC implementation.

Understand the Testing Phases

Business Central implementations should follow a clear testing progression. Each phase has a distinct purpose, and skipping phases creates compounding risk.

• Unit testing — the implementation partner tests individual configurations and customisations. Does the posting group configuration post to the correct GL account? Does the AL extension trigger at the right point? This is the partner's responsibility
• System Integration Testing (SIT) — tests that modules work together correctly. A sales order flows from entry through to posted invoice and creates the correct GL entries, inventory movements, and VAT entries. SIT is typically partner-led with client observation
• User Acceptance Testing (UAT) — business users validate that they can complete their real-world processes on the system. This is business-led. If your consultants are executing the tests, it's not UAT — it's extended SIT

Organise by Business Process, Not Module

This is where most BC test plans go wrong. They're structured around the BC menu: "Finance tests", "Sales tests", "Purchasing tests". But that's not how your business works. Your users don't think in modules — they think in processes.

Structure your test plan around end-to-end business processes:

• Procure-to-pay — from purchase requisition through to supplier payment and GL posting
• Order-to-cash — from sales order entry through to customer invoice and cash receipt
• Inventory receipt-to-consumption — from goods receipt through to warehouse put-away, pick, and eventual sale or production consumption
• Record-to-report — from journal entry through to trial balance, management reporting, and statutory returns
• Hire-to-retire (if using HR/payroll integration) — from employee onboarding through to payroll processing and GL integration

Write Test Cases Business Users Can Follow

Your AP clerk does not need to know that they're testing the "Purchase Invoice Posting Routine". They need clear, step-by-step instructions written in plain English:

Notice the specificity: real vendor numbers, real account numbers, real dimension values. This is what separates a useful test case from a vague instruction. For more guidance, see our complete guide on how to run effective UAT.

4. Common Mistakes in Business Central UAT

Having been through dozens of BC go-lives, certain mistakes appear with depressing regularity. Here are the ones that cause the most damage.

5. Getting Sign-Off Without the Chaos

UAT sign-off on a Business Central project should not be a single event. It should be a structured process that builds confidence incrementally and gives decision-makers a clear, evidence-based view of readiness.

Define What "Signed Off" Actually Means

Before UAT begins, agree with all stakeholders what sign-off means. This sounds obvious, but it's remarkably common for different people to have different interpretations. Define it explicitly:

• All critical and high-severity test cases have passed — define your severity categories upfront
• All critical defects are resolved and retested — not just logged, not just "in progress", but fixed, deployed to UAT, and confirmed by the original tester
• Medium-severity defects have agreed workarounds — with a documented plan for post-go-live resolution
• Data migration has been validated — opening balances reconcile and master data has been tested inside real transactions
• Each business area has a named sign-off authority — typically the department head or process owner, not the project team

Structure the Sign-Off Process

Break sign-off into layers rather than treating it as one monolithic decision:

Dealing with Conditional Sign-Offs

In practice, UAT sign-off is rarely unconditional. There will always be outstanding items. The key is to manage them transparently:

• Document every condition — if finance signs off with the condition that the bank reconciliation import format is fixed by go-live, write it down with a deadline and an owner
• Categorise outstanding items — distinguish between "must fix before go-live", "workaround available, fix post-go-live", and "cosmetic, fix in next release"
• Make conditions visible to decision-makers — the person making the go/no-go decision needs to see the full picture, not a sanitised summary. A centralised UAT platform makes this visibility automatic rather than relying on manual reporting