Microsoft’s Wave 1 2026 announcement for Business Central is unlike any previous release. Every wave before this one updated existing functionality, new fields, improved UI, performance enhancements. Wave 1 2026 introduces something architecturally different: AI agents that act autonomously inside Business Central, processing invoices, creating sales orders, and executing financial workflows without direct human interaction.
This changes what Business Central test automation means. It is no longer just about validating that the UI works correctly after an update. It is about validating that an AI agent inside your ERP is making correct decisions, matching invoices accurately, assigning the right GL codes, creating orders with correct pricing rules, and producing financial outcomes that auditors can rely on.
For BC teams that have been getting by with manual testing, ad hoc AL test scripts, or the basic test framework that ships with Business Central, Wave 1 2026 is the forcing function. The workflows that need testing just became significantly more complex, and the consequences of undetected errors in AI-driven ERP workflows are significantly higher than in human-driven ones.
This guide covers what makes BC testing different from D365 Finance & Operations testing, exactly what Wave 1 2026 introduces and why each new feature needs automated validation, the persistent challenge of AL code testing, and how AI test agents designed for Business Central handle the workflows that script-based tools were never built for.
For the broader D365 test automation landscape, including Finance, Supply Chain, and Sales modules, the complete guide to Dynamics 365 test automation maps how Sofy’s agents work across the full D365 platform.
1. Why Business Central Test Automation Is Different from D365 F&O Testing
Business Central and Finance & Operations share a Microsoft parentage and a D365 branding, but they are built on different codebases, serve different market segments, and have fundamentally different testing challenges. Understanding these differences is what separates a BC testing strategy that works from one borrowed from the F&O playbook that doesn’t.
| Dimension | D365 Business Central | D365 Finance & Operations |
| Target market | SME and mid-market | Enterprise (large organisations) |
| ERP architecture | All-in-one SaaS, single codebase | Modular, Finance, SCM, Sales as separate apps |
| Customisation language | AL (Application Language) | X++ and extensions |
| Update cadence | 2 major waves + continuous SaaS updates | 2 major waves + service updates |
| Testing tool (native) | No RSAT equivalent, AL Test Framework | RSAT (now feature complete) |
| Wave 1 2026 additions | AI agents (Payables, Sales Orders, custom) | Copilot enhancements, no new native agents |
| Testing complexity | AL extensions + AI agent workflows | Cross-module E2E + financial compliance depth |
The most significant difference from a testing perspective is the native tooling gap. D365 Finance & Operations ships with RSAT, Microsoft’s Regression Suite Automation Tool, which, despite its well-documented limitations, at least gives teams a starting point for automated regression. Business Central has no equivalent. The AL Test Framework that ships with BC is designed for unit testing AL code, not for end-to-end business process validation.
This means BC teams building Business Central test automation from scratch are starting from a lower baseline than F&O teams. Most BC QA coverage is manual or semi-automated at best. Wave 1 2026 is arriving into an environment where the testing infrastructure is, for most BC customers, not ready for what is about to be deployed.
“Most Business Central environments have never had proper automated test coverage. Wave 1 2026 is introducing AI-driven workflows into those same environments. The gap between what needs testing and what is being tested is about to get significantly larger.”
2. What Wave 1 2026 Introduces to Business Central, and Why It Changes Testing
Microsoft’s Wave 1 2026 release for Business Central (April–September 2026) makes a significant architectural shift: AI agents move from being Copilot suggestions to being autonomous workflow executors inside BC. Microsoft has explicitly described this as “accelerating the move to agentic ERP”, agents that reason over Business Central data, understand business context, and take actions on behalf of users.
Here are the five Wave 1 2026 additions that change what Business Central test automation must cover:
| Wave 1 2026 feature | What it does in Business Central | What needs testing |
| Accounts Payable Agent | Automates invoice matching, coding, and posting approval workflows in BC Finance | Invoice match accuracy · GL account assignment · payment terms applied correctly · agent override logging |
| Sales Order Agent | Creates and updates sales orders from email/natural language, triggers fulfilment | Order data accuracy · pricing rules applied · inventory availability check · ERP handoff to warehouse |
| Custom Agent Toolkit | Allows organizations to build their own BC agents for any internal workflow | Custom workflow outcome validation · error handling · data integrity across the steps the agent executes |
| Copilot Financial Summaries | AI-generated period summaries and trial balance narratives in Finance | Output accuracy against underlying ledger data · narrative correctness · no hallucination on financial figures |
| Automated Bank Reconciliation (enhanced) | BC agent matches bank statement lines to ledger entries with higher accuracy | Match rate validation · unreconciled item handling · bank balance agrees to ledger balance |
The critical testing challenge these features introduce is not that they are technically complex, it is that they shift the validation requirement from “did the UI display the correct result” to “did the AI agent make the correct decision.” These are different questions that require different testing approaches.
A traditional UI test for the Accounts Payable agent would confirm that the agent opened the invoice screen and clicked the correct buttons. What actually needs validating is whether the agent matched the invoice to the correct purchase order, applied the correct tax code, assigned the correct GL account, and triggered the approval workflow with the correct approver, based on the financial rules configured in BC. That is outcome validation, not UI validation.
Why AI agent output needs validation more rigorously than human input
When a human processes an invoice manually, they read the invoice, check the details against the purchase order, and apply their knowledge of the GL chart to code it correctly. Errors are usually caught by the human in the process, by an approver, or during bank reconciliation. The failure rate is low because the human brings contextual understanding to every decision.
When an AI agent processes an invoice, it applies pattern matching and configured rules at scale. A configuration error, an ambiguous invoice, or an edge case outside the agent’s training data will be applied consistently at volume, not occasionally. A mis-coded GL account that a human would catch on the first invoice will be replicated across every invoice the agent processes until someone notices. At that point, the remediation effort is proportional to the volume, not to the original error.
3. The AL Code Challenge: Why Script-Based BC Testing Breaks Constantly
Business Central’s customization model is built on AL (Application Language), a modern, extension-based language that replaces the older C/AL used in NAV. AL extensions are how BC partners and customers customize and extend Business Central: adding new fields, modifying workflows, integrating with external systems, and building industry-specific functionality on top of the standard platform.
AL extensions create a persistent testing challenge that every BC team encounters, usually painfully:
The extension update problem
When Microsoft releases a Wave update, AL extensions that were built against the previous platform version may break. A field that an extension referenced may have moved. A method that an extension called may have changed its signature. An interface that an extension implemented may have been updated. Every Wave release is potentially a breaking change for custom AL code, and the only way to find out is to test.
Script-based BC testing tools that were built against a specific version of the platform will also break on the same Wave update, for the same reason. The brittle coupling that makes AL extensions fragile on Wave updates makes testing scripts equally fragile.
The test isolation problem
Business Central’s end-to-end workflows span multiple functional areas, finance, purchasing, sales, inventory, projects, which are all interconnected in a single-tenant SaaS environment. Testing a purchasing workflow in isolation confirms that the purchase order form works. It does not confirm that the goods receipt correctly updates inventory, that the invoice correctly posts to AP, and that the AP posting correctly updates the GL, all of which depend on AL extension code running correctly in sequence.
The AL Test Framework that ships with BC is designed to test individual AL functions and procedures, unit testing, not process testing. It runs against the BC Docker container or a sandbox, not against the production data and configuration. It cannot validate that an end-to-end business process produces the correct financial outcome in a configured BC environment.
The Wave regression problem
Every Wave release requires BC teams to re-validate their entire extension portfolio against the new platform version. For teams relying on manual testing or ad hoc AL scripts, this means a regression cycle that can take weeks, the same Wave maintenance burden that RSAT creates for F&O teams. The difference is that BC teams often have more AL customisation than F&O teams, making the regression surface larger.
The AL challenge in plain terms: Scripts break when the platform changes. The platform changes twice a year. The only BC testing approach that survives this cycle is one that understands what the process is supposed to produce, not which AL methods it calls to get there.
4. How Sofy’s Business Central Agent Automates ERP Workflow Testing
Sofy’s Business Central agent is built on the same architectural principle as the D365 Finance, Supply Chain, and Sales agents: it understands business process intent, not UI state. The distinction matters for BC in exactly the same way it matters for F&O, but with the additional dimension of AI agent output validation that Wave 1 2026 makes necessary.
Process outcome validation, not AL method testing
Sofy’s BC agent does not test individual AL functions. It tests whether the BC environment produces the correct business outcomes when business processes are executed. For a purchase order workflow, that means: was the correct vendor selected, was the correct GL account assigned, did the goods receipt update inventory with the correct quantities and values, did the invoice match correctly, and did the final AP posting produce a balanced ledger entry? The validation is financial and operational, not technical.
Self-healing through Wave updates
When Wave 1 2026 updates the BC interface or modifies a workflow, Sofy’s BC agent adapts automatically. The process intent, validate a purchase order from creation through GL posting, does not change because Microsoft reorganised a form or added a required field. The agent detects the change and re-routes to the same validated outcome. No AL script to rebuild. No manual test to re-record.
AI agent output validation, the Wave 1 2026 requirement
For the new AI-driven workflows introduced in Wave 1 2026, Sofy’s BC agent validates the outputs that the BC AI agents produce, not the UI interactions that triggered them. For the AP Agent, that means validating the invoice match decision, the GL code assignment, and the payment terms applied. For the Sales Order Agent, that means validating the order data accuracy, pricing rules applied, and ERP handoff correctness. Sofy produces field-level assertion logs for each decision the BC AI agent makes, creating the audit trail that manual inspection of AI output cannot provide at scale.
No developer required
Building AL test scripts requires developers. Running the BC AL Test Framework requires a developer-configured Docker container or sandbox setup. Sofy’s BC agent requires neither. BC consultants, QA leads, and functional analysts can build, run, and maintain Business Central test automation without writing a line of AL code. For BC partner organizations building test coverage for multiple clients, this changes the economics of test automation entirely.
5. Business Central Test Automation Checklist: 8 Scenarios to Automate Before Every Wave
For BC teams building test coverage incrementally, this checklist prioritises by a combination of financial risk and Wave 1 2026 exposure. Scenarios 1–5 are High priority because they involve either core financial processes or the new Wave 1 AI agent features that introduce the most risk if they malfunction silently.
| # | BC Scenario | What to validate | Priority |
| 1 | Purchase order → Invoice → GL posting (P2P) | 3-way match accuracy · posting profile · GL account · period assignment | High |
| 2 | Sales order → Pick → Ship → Invoice (O2C) | Order fulfilment accuracy · pricing · inventory update · AR posting | High |
| 3 | Accounts Payable AI agent, invoice processing | Agent invoice match rate · GL code assignment · approval workflow triggered correctly | High |
| 4 | Sales Order AI agent, order creation | Order data accuracy from email/natural language · pricing rules · ERP handoff | High |
| 5 | Bank reconciliation (enhanced AI matching) | Match rate · unreconciled items handled correctly · bank balance agrees to ledger | High |
| 6 | Project billing and revenue recognition | Time entry → project cost → billing milestone → revenue posting sequence | Med |
| 7 | Intercompany transactions (if multi-entity) | Both-side posting · elimination entry · period alignment | Med |
| 8 | AL extension regression after Wave update | Custom AL code behaviour unchanged · field mappings correct · no performance degradation | Med |
A note on the AL extension regression scenario (item 8): this is listed as Medium priority not because it is low-risk, but because the risk profile depends entirely on how much custom AL code is in your BC environment. Partners with complex, industry-specific AL extensions should treat this as High priority and build regression coverage for every AL extension before each Wave deployment.
For teams that are new to automated BC testing, the practical starting point is items 1 and 2, the core P2P and O2C cycles. These are the highest-frequency processes in any BC environment and the ones where silent failures have the most immediate operational and financial impact. Once those are covered and passing consistently, items 3 and 4 (the Wave 1 2026 AI agent features) become the next priority.
Automate your Business Central testing before Wave 1 2026 reaches production.
Sofy’s Business Central agent validates standard BC workflows and AI agent outputs, no AL scripting, no developer dependency, no Wave regression sprints. Explore Sofy D365 Test Agents
Frequently Asked Questions
Business Central test automation is the use of software agents or tools to automatically validate that BC business processes, purchasing, sales, finance, inventory, projects, produce correct outcomes after system updates, configuration changes, or AL extension deployments. With Wave 1 2026 introducing autonomous AI agents inside BC, test automation now also includes validating the output of those AI agents, confirming they make correct decisions, not just that they execute.
No. D365 Finance & Operations ships with RSAT (Regression Suite Automation Tool) as a native testing tool. Business Central has the AL Test Framework, which is designed for unit testing individual AL functions, not for end-to-end business process testing. This means BC teams building comprehensive test coverage need a third-party solution. Sofy’s Business Central agent fills this gap with no-code, process-level test automation that self-heals through Wave updates.
Wave 1 2026 introduces autonomous AI agents inside Business Central, including the Accounts Payable Agent, the Sales Order Agent, and a custom agent toolkit. These agents take actions autonomously: processing invoices, creating orders, executing financial workflows without direct human interaction. Testing these features requires validating AI agent output, whether the agent made correct decisions, not just whether it completed the workflow. This is a new testing requirement that traditional UI automation tools and the AL Test Framework were not designed to address.
Yes. Sofy’s Business Central agent tests business process outcomes regardless of whether the underlying implementation uses standard BC functionality or custom AL extensions. Because the agent validates outcomes at the process level, was the correct GL account posted, did inventory update correctly, did the order price apply correctly, it covers both standard and customized workflows in the same test run. Wave update regression testing for AL extensions is supported through the same self-healing mechanism that adapts to standard BC UI changes.
