What Business Central Consultants Get Wrong About Testing
I've implemented Business Central for manufacturing firms, distributors, professional services companies, and healthcare providers. I've seen the same testing mistakes on almost every project. Here's what BC consultants get wrong, and what we should be doing instead.
Mistake #1: Treating UAT Like a Formality
Too many BC consultants treat UAT as a box-ticking exercise before go-live. The system's been configured. The data's been migrated. Training's been delivered. UAT is just "let the client click around for a week to make sure they're happy".
The Problem
Business Central is deceptively simple to configure, which makes consultants overconfident. You set up the chart of accounts, configure posting groups, map dimensions, import customers and items. It looks right in the UI. You assume it'll work in production.
Then the client goes live and discovers that inter-company postings don't balance, or inventory revaluation is calculating incorrectly, or VAT reporting is missing transactions. All things that would have been caught during proper UAT.
What to Do Instead
Treat UAT as your safety net. It's the only chance you get to validate that the configured system actually handles the client's business scenarios correctly. Don't treat it as a formality. Treat it as the most important validation phase in the project.
Write structured test cases for every configured area. Finance, inventory, purchasing, sales, service. Map them to actual business processes the client will run on day one. If you've configured it, test it.
Mistake #2: Testing Happy Paths Only
BC consultants write test cases that follow the standard process flow: create a sales order, post a shipment, post an invoice, receive payment. Everything works perfectly because you're testing the Microsoft-documented process.
The Problem
Real business doesn't follow happy paths. Clients need to:
- Post partial shipments and then invoice the remainder
- Reverse posted invoices and re-post with corrections
- Handle returns where the original sales order is three months old
- Process credit notes for partially paid invoices
- Transfer inventory between locations mid-month and reconcile costing
These scenarios break. Not because BC can't handle them, but because your configuration assumes the happy path.
What to Do Instead
Spend time with the client's operations team before UAT. Ask them: "What goes wrong in your current system? What edge cases do you deal with weekly?" Then write test cases specifically for those scenarios.
Test error conditions explicitly: what happens when a user tries to post an invoice with insufficient inventory? What happens when someone tries to delete a customer with open ledger entries? What happens when cost adjustment runs mid-month?
The goal isn't to test that BC works. BC works. The goal is to test that your configuration handles the client's actual business scenarios correctly.
Mistake #3: Not Testing Month-End Before Go-Live
This one's killed more BC implementations than any other mistake. Consultants test daily transactions (sales orders, purchase invoices, payments) but don't run a full month-end close during UAT.
The Problem
Month-end in BC isn't just posting journals. It's:
- Adjust cost - item entries (inventory revaluation)
- Calculate and post depreciation (if using fixed assets)
- Reconcile customer and vendor ledgers
- Run VAT settlement and reporting
- Inter-company reconciliation and elimination (if multi-company)
- Period close and reporting
If you don't test this end-to-end during UAT, you're gambling that everything will work the first time the client tries to close a month in production. That gamble usually loses.
Real Example
I once worked on a BC implementation for a distribution company. We tested daily transactions thoroughly. Sales, purchasing, inventory, payments. All good. We went live mid-month.
End of month one, the finance team ran "Adjust Cost - Item Entries". It took nine hours to complete (normally takes twenty minutes). The inventory valuation report didn't match the GL. We spent three days debugging before discovering that a costing method configuration for one item category was causing the batch job to loop infinitely.
That issue would have been caught if we'd run a full month-end during UAT.
What to Do Instead
Include a full month-end close cycle in your UAT plan. Use dummy data if you have to, but walk through every step the client will perform at month-end. Run the batch jobs. Generate the reports. Reconcile the ledgers.
Time how long each step takes. If "Adjust Cost" is taking hours instead of minutes, that's a configuration issue you need to fix before go-live, not after.
Mistake #4: Assuming Standard Reports Are Enough
BC comes with solid standard reports. Trial balance, aged receivables, inventory valuation, VAT statements. Most consultants assume that's enough and don't test reporting during UAT.
The Problem
Clients don't just need reports. They need their reports. The formats their bank requires. The breakdowns their auditors expect. The analysis their management team reviews weekly.
If you haven't tested that BC can produce the reports the client actually needs, you'll discover post-go-live that half their reporting requirements can't be met without custom development or third-party tools.
What to Do Instead
During requirements gathering, ask the client for copies of the five reports they run most frequently. Then add test cases to UAT that validate BC can produce those reports with the right data, right format, right breakdowns.
If BC can't produce a required report out of the box, you need to know that before go-live so you can build custom reports, configure Power BI, or set client expectations.
Mistake #5: Not Testing Data Migration Outcomes
BC consultants test the data migration process (scripts run, records import, no errors), but they don't test whether the migrated data actually works in the new system.
The Problem
Data can import successfully but still be unusable:
- Customer ledger entries import, but aged receivables report doesn't match the legacy system
- Item ledger entries import, but inventory valuation is wrong because costing methods differ
- Open sales orders import, but you can't ship them because reservation entries are missing
- Chart of accounts imports, but dimension mappings are broken so P&L reporting is unusable
The migration succeeded technically. It failed functionally.
What to Do Instead
After you migrate data into the UAT environment, don't just check that records exist. Test business scenarios using the migrated data:
- Can you post a payment against a migrated open invoice?
- Can you ship a migrated open sales order?
- Do aged receivables reconcile to the legacy system?
- Does inventory valuation match what the client expects?
- Do P&L and balance sheet reports match legacy period-end reports?
If migrated data doesn't behave correctly, fix it before go-live. Don't assume "we'll sort it out after go-live". You won't have time.
The Bottom Line
Business Central is a brilliant ERP system. It's also unforgiving when you skip proper testing. These five mistakes are entirely preventable, but they keep happening because consultants underestimate how much can go wrong between "configured correctly" and "works in production".
I built LogicHive specifically for BC consultants who want to run UAT properly. Test case templates for standard BC processes. Evidence capture for month-end validation. Defect tracking that doesn't rely on email chains. Multi-client dashboards for consultancies managing multiple BC rollouts simultaneously.
It's the tool I wished existed when I was implementing BC and making these mistakes myself.
Run Business Central UAT Properly
LogicHive is purpose-built for BC consultants who want structured UAT without enterprise complexity. Test case templates, multi-client management, month-end validation workflows, and go-live sign-off tracking.
Written by Reece Hallam
Sales Director
Reece brings over 15 years of experience in ERP implementations, specialising in Business Central and Dynamics 365. He has led UAT programmes for mid-market manufacturing and distribution clients across the UK and Europe.
View all articles by Reece Hallam