Business Central’s 2026 Wave 1 release put a real AI agent into the heart of accounts payable. The Payables Agent now watches a mailbox, reads incoming PDF invoices, matches them to vendors and accounts, and prepares the invoice for approval, turning a manual data-entry grind into a queue of ready-to-review drafts. For the small and mid-sized teams that run on Business Central, often without a dedicated QA function, that is a genuine step forward.
It also quietly changes where the risk lives. The agent does not pay anyone; it drafts. But that draft goes to a human approver who, in a busy AP function, may glance and click Approve. If the agent extracted the wrong amount, matched the wrong vendor, or coded the invoice to the wrong GL account, the error does not get caught by the agent, it gets caught by the approver, if the approver catches it at all. The question this article answers is how to make sure the drafts are right before they ever reach that approval screen, and how Sofy validates the agent’s output at the data layer to do exactly that.
What the Payables Agent actually does, and what it doesn’t
Testing anything starts with knowing precisely what it does. The Business Central Payables Agent is a native, generally available agent that automates the front end of accounts payable, but within clearly defined boundaries that matter enormously for how you test it.
What it does
- Monitors a mailbox for incoming invoices. The agent watches a designated inbox and picks up vendor invoices as they arrive, rather than waiting for someone to key them in.
- Reads the PDF with AI. It extracts the invoice data from the PDF attachment, vendor, amounts, dates, line items, using AI rather than a rigid template.
- Matches vendors and accounts. It identifies the correct vendor record and the appropriate accounts in Business Central, then assembles a draft invoice.
- Prepares the invoice for human approval. The output is a reviewable draft routed to a person, the agent stops at the approval gate. It does not post or pay.
What it doesn’t do (yet)
Just as important are the documented boundaries. At this stage the Payables Agent does not perform purchase-order matching, does not route approvals itself, and does not do anomaly detection. It also operates within hard throughput limits, on the order of 100 emails and 500 invoices per day, with PDF size and attachment caps, and is available only on cloud (SaaS) Business Central. These are not footnotes. Every one of them is a place where an untested assumption can let a bad invoice through, which is why they belong in your test plan, not just your release notes.
Why this is a testing problem, not a rollout problem Most Business Central environments have never had proper automated test coverage, BC ships only the AL Test Framework for unit-testing code, with no RSAT-style tool for business-process testing. Now an AI agent is drafting financial documents inside those same untested environments. The gap between what needs validating and what is actually being validated just widened, and the Payables Agent sits right in the middle of it.
Why a “human-in-the-loop” agent still needs rigorous testing
It is tempting to assume that because a human approves every invoice, the human is the safety net and the agent doesn’t need much testing. That reasoning is comforting and wrong, for two reasons.
First, the human-in-the-loop only works if the human actually scrutinizes each draft, and the entire value proposition of the agent is to let them stop doing that. An AP clerk who used to key every invoice by hand was, in effect, validating each one. An approver reviewing a queue of clean-looking AI drafts is under pressure to move fast, and a draft that looks right is far more likely to be waved through than a blank form that had to be filled in. The agent doesn’t remove the risk of a wrong invoice; it makes a wrong invoice look finished.
Second, the agent makes systematic errors, not random ones. A human miskeys one invoice; an AI agent that misreads a particular vendor’s layout, or consistently mis-codes a certain expense type, gets it wrong the same way every time, at scale, across hundreds of invoices a day. That is precisely the kind of error that testing is built to catch and manual review is worst at spotting, because each individual instance looks plausible.
The failure mode that matters most The dangerous outcome isn’t the invoice the agent flags as uncertain, that one gets attention. It’s the wrong invoice the agent drafts with full confidence: correct-looking, cleanly matched, sitting in the approval queue indistinguishable from the good ones. If your testing only confirms “the agent produces a draft,” you have tested the thing that was never in doubt. What has to be proven is that the draft is correct.
Testing the extraction and matching decision
The core of Payables Agent testing is validating the two decisions that determine whether a draft is right: what the agent read off the invoice, and what it matched that invoice to. Both have to be checked against a known-correct answer, not eyeballed on screen.
Extraction accuracy, did it read the invoice correctly?
For a controlled set of invoices where you already know every value, confirm the agent extracted them correctly: the total, the tax, the currency, the invoice date and number, and the line-item detail. Deliberately include the hard cases AI extraction gets wrong, unusual vendor layouts, multi-page PDFs at the size limit, invoices with handwriting or stamps, credit notes, and foreign-currency documents. An extraction that is close but off by a transposed digit or a misread decimal is exactly the error a rushed approver will miss.
Matching accuracy, did it pick the right vendor and account?
Confirm the agent resolved the correct vendor record, including the confusable cases: vendors with similar names, the same vendor under multiple records, or a new vendor that shouldn’t match anything at all. Then validate the account coding: did it assign the GL account and dimensions this invoice should carry? Mis-coding doesn’t stop a payment, but it quietly corrupts your financial reporting, and it is the kind of systematic error that repeats across every invoice of a given type until someone tests for it.
| Decision | What “correct” means | A realistic failure to test for |
| Extraction | Every field matches the source invoice exactly | A misread total or a transposed digit on an odd layout |
| Vendor match | Resolves to the right vendor record | Two similar vendor names resolve to the wrong one |
| Account coding | Correct GL account and dimensions assigned | An expense type consistently mis-coded across many invoices |
| New/unknown vendor | Correctly treated as new, not force-matched | A first-time vendor matched to an existing record |
Testing the approval gate and the documented limits
The Payables Agent’s defining safety feature is that it stops at approval. That gate, and the boundaries around it, have to be tested directly, not assumed to hold because the documentation says so.
- The gate holds every time. Confirm that no configuration, invoice type, or edge case lets a draft bypass human review and post on its own. The one thing this agent must never do is complete an invoice without approval, prove it can’t.
- The documented gaps behave as gaps. The agent doesn’t do PO matching, approval routing, or anomaly detection. Test that it visibly leaves those to your existing process rather than silently producing a draft that looks PO-matched when it isn’t, a false impression of completeness is its own risk.
- The throughput limits fail safely. Test what happens at the daily email/invoice caps and the PDF size and attachment limits. Confirm that an invoice over the limit is clearly not processed, not silently dropped, which would leave a real payable unrecorded with no one aware.
That last point is the quiet danger of any capped automation: the failure you can’t see. An invoice that exceeds a limit and simply never appears is worse than one that errors loudly, because the missing payable surfaces only when a vendor chases the payment. Testing the boundaries is how you turn a silent drop into a visible exception.
How Sofy validates Payables Agent drafts at the data layer
Validating an AI agent that drafts financial documents requires checking the draft against a known-correct expectation, in the data, before it reaches a human, which is exactly how Sofy’s Business Central testing agent works. Sofy fills the gap Business Central leaves open: process-level, no-code test automation for teams that have never had it.
Validate the draft, not the screen
For a controlled set of invoices with known-correct answers, Sofy confirms what the Payables Agent extracted and matched, vendor, amounts, tax, GL coding, dimensions, against the expected result at the data layer. A draft that looks clean in the approval queue but carries a misread amount or a mis-coded account still fails the test, because the validation runs against the underlying data, not the tidy summary an approver sees. This is what “validating invoices before they reach approval” means in practice: catching the bad draft while it is still a test case, not after it is a posted payable.
A field-level record for every drafted invoice
Each invoice Sofy validates produces a field-level assertion log: the source values, the agent’s extracted and matched values, the expected result, and a pass or fail on each field. For an AP process that has to satisfy auditors, that per-invoice record is the evidence that the agent is drafting correctly, not a general assurance that it “works,” but proof, invoice by invoice, that extraction and coding are right.
No-code, and built for how Business Central teams actually work
Business Central runs on small teams without QA specialists or AL developers to spare. Sofy’s agent is no-code and process-level: a controller or AP lead can define what a correct invoice looks like and validate the agent against it, without writing AL or standing up a test framework. And because Sofy self-heals through Business Central’s wave updates, the tests keep working as Microsoft expands the Payables Agent, which it will, toward PO matching and beyond.
Getting started: validate your highest-volume vendors first
You don’t need to validate every invoice type on day one. The fastest way to build confidence is to test where the agent does the most work and a systematic error would repeat most often.
- Start with your highest-volume vendors. The vendors that send the most invoices are where a consistent extraction or coding error compounds fastest, validate those layouts first.
- Build a known-answer invoice set. In a sandbox, assemble invoices where you know every correct value and coding, including the tricky layouts and a deliberate new-vendor case.
- Validate extraction, matching, and the gate. Confirm the drafts are correct at the data layer and that the approval gate and documented limits behave as they should.
- Keep the evidence, then widen coverage. Retain the per-invoice assertion log as your audit baseline and extend to the next vendor group or invoice type.
Done this way, the Payables Agent becomes what it should be for a lean finance team: a genuine accelerator you can trust, because you have proven the drafts are right before anyone approves them.
Frequently asked questions
What is the Business Central Payables Agent?
It is a native AI agent in Dynamics 365 Business Central, introduced in the 2026 Wave 1 release, which automates the front end of accounts payable. It monitors a mailbox for incoming vendor invoices, reads the PDF attachments using AI, matches vendors and accounts in Business Central, and prepares a draft invoice for human approval. It does not post or pay invoices, a person approves each one.
If a human approves every invoice, why test the Payables Agent?
Because the human-in-the-loop only protects you if the approver scrutinizes each draft, and the agent’s purpose is to let them stop doing that. A wrong invoice that looks finished is more likely to be waved through than a blank form. AI agents also make systematic errors, misreading a particular vendor’s layout or mis-coding an expense type the same way across hundreds of invoices, which manual review is especially poor at catching. Testing validates the drafts are correct before they reach approval.
What should Business Central AP automation testing cover?
Four things: extraction accuracy (did the agent read every invoice field correctly), matching accuracy (did it resolve the right vendor and GL coding), the approval gate (does it always stop for human review and never post on its own), and the documented limits (PO matching, approval routing, and anomaly detection are not supported, and throughput caps must fail visibly rather than silently dropping an invoice).
What are the current limits of the BC Payables Agent?
As documented for the 2026 Wave 1 release, the agent does not perform purchase-order matching, approval routing, or anomaly detection, and it operates within throughput limits (on the order of 100 emails and 500 invoices per day, with PDF page, size, and attachment caps). It is available only on cloud (SaaS) Business Central. These limits should be validated as real boundaries, so that an over-limit or unsupported invoice produces a visible exception rather than a silent gap.
How does Sofy validate the Payables Agent’s invoices?
Sofy’s Business Central testing agent validates each drafted invoice at the data layer against a known-correct expectation, confirming the extracted values, vendor match, and GL coding, before the draft reaches a human approver. Every invoice produces a field-level assertion log as audit evidence, the approach is no-code so lean BC teams can use it without AL or a test framework, and it self-heals through Business Central wave updates as the agent evolves.
Catch the Wrong Invoice Before Your Approver Does
Sofy’s Business Central testing agent validates every invoice the Payables Agent drafts, extraction, vendor match, and GL coding, at the data layer, with a field-level record per invoice. Right before approval, not after posting.
