Reconciling sub ledger balances to the general ledger is one of the highest-trust tasks in finance. Get it right and the books close cleanly; get it wrong and you have a misstatement sitting in your financials. With the 2026 release wave, Microsoft handed that task to an AI: the Dynamics 365 Account Reconciliation Agent now matches sub ledger transactions to the GL automatically, on a schedule, and flags what it cannot resolve. It is one of the most useful agents in Dynamics 365, and one of the most consequential to get wrong.
Which raises a question almost no one is answering: how do you test it? Plenty of partner blogs explain how to switch the agent on and tune its rules. Far fewer explain how to prove the matches it makes are correct and the exceptions it raises are complete, which is the only thing that actually protects the ledger. This article closes that gap. We will look at what the agent does autonomously, why watching it work in the UI tells you nothing, the four things you must actually validate, and how to produce the audit evidence a controller can sign off on.
What the Account Reconciliation Agent actually does autonomously
The Account Reconciliation Agent is a Copilot-powered workflow built into Dynamics 365 Finance. Rather than waiting for a period-end SSRS report, it runs continuously in the background on a scheduled cadence, comparing sub ledger postings to the general ledger and acting on what it finds. Understanding exactly what it does on its own is the starting point for knowing what to test.
- It auto-matches and auto-reconciles. Transactions that clearly match between a sub ledger and the GL are reconciled automatically, across accounts payable, accounts receivable, bank, and tax, with inventory added in the 2026 wave. This is the agent acting without a human in the loop.
- It matches on configurable logic. Matching keys such as voucher, date, and amount, combined with tolerance and fuzzy rules, drive one-to-one, one-to-many, and many-to-many matches. Those rules are settings, which means they can be set wrong.
- It raises typed exceptions. What it cannot reconcile with confidence becomes an exception in one of three categories: in sub ledger not in ledger, in ledger not in sub ledger, or amount mismatch. For each, it suggests a corrective action and attaches an AI-generated justification.
- It logs every action, and can undo it. Each match and exception is recorded with a rationale, and every reconciled item carries an undo that returns it to an unmitigated state. That log is where testable evidence lives.
The core risk in one line Every transaction the agent auto-reconciles is a decision no human reviewed. A correct auto-match saves hours. An incorrect one clears a real discrepancy silently, and a discrepancy that has been marked “reconciled” is far harder to catch than one sitting in an exception queue. That is precisely the outcome testing has to prevent.
Why a passing UI says nothing about a correct match
The instinct with any new D365 feature is to validate it the way you validate a form: click through the workspace, watch the agent reconcile some transactions, see green tiles, and call it tested. For this agent, that instinct is actively misleading.
The reason is that the agent’s work is invisible at the interface. When it auto-reconciles a transaction, the workspace shows you that something was reconciled, not whether it was reconciled correctly. A match between the wrong two transactions looks identical, on screen, to a match between the right two. An exception the agent should have raised but did not simply is not there to see; the absence of a flag is not something a UI walkthrough can surface. The screen confirms the agent ran. It cannot confirm the agent was right.
Correctness lives one layer down, in the data: which sub ledger transaction was matched to which GL entry, whether the amounts and dimensions truly correspond, and whether every genuine discrepancy actually became an exception. You cannot see that by watching the workspace. You can only see it by validating the matching decisions themselves, at the data layer, against a known-correct expectation.
The four things you must validate
Testing the Account Reconciliation Agent means checking four distinct things. Skip any one and you have a blind spot that a clean-looking workspace will happily hide.
1. Match accuracy, did it match the right transactions?
The foundational test. For a controlled set of transactions where you know the correct pairing in advance, confirm that the agent matched each sub ledger item to the correct GL entry not merely that it found something to match. This has to cover the hard cases the 2026 agent now handles: one-to-many and many-to-many matches, where the opportunity to pair the wrong combination is far higher than in a simple one-to-one. A false match here is a cleared discrepancy that should never have cleared.
2. Exception logic, did it raise every exception it should have?
The mirror image of match accuracy, and the one most testing misses. You are validating completeness: seed known discrepancies of each type, in sub ledger not in ledger, in ledger not in sub ledger, and amount mismatch, and confirm the agent flagged everyone. The failure mode to hunt for is the false negative: a real discrepancy the agent quietly auto-reconciled instead of raising. An exception that never appears is the most dangerous outcome the agent can produce, precisely because nothing on screen tells you it is missing.
3. Threshold configuration, are the tolerances set correctly?
The agent’s tolerance and matching rules are a dial, and both extremes are wrong. Set too tight, the agent floods the team with exceptions and the noise buries the real ones. Set too loose, it absorbs genuine discrepancies inside the tolerance band and auto-reconciles them away. Testing threshold configuration means proving that amounts just inside your tolerance are correctly accepted and amounts just outside it are correctly flagged, validating the boundary itself, not just the happy path in the middle.
4. Audit trail, can you prove what it did and why?
Because these are financial decisions made autonomously, the agent’s log is not a convenience, it is audit evidence. Testing the audit trail means confirming that every match and exception is recorded with a rationale, that the record ties the specific sub ledger transaction to the specific GL entry, and that the trail is complete enough for a controller or external auditor to reconstruct and trust each decision. “The agent said it reconciled” is not something an auditor will accept on faith; a verifiable, per-decision record is.
| What to validate | The question it answers | The failure it catches |
| Match accuracy | Did it pair the correct transactions? | A false match that clears a real discrepancy |
| Exception logic | Did it flag every true discrepancy? | A false negative, a discrepancy silently auto-reconciled |
| Threshold config | Are tolerances accepting/flagging at the right boundary? | Noise (too tight) or absorbed errors (too loose) |
| Audit trail | Can each decision be reconstructed and proven? | An unauditable, unexplainable autonomous action |
How Sofy validates matches at the data layer
All four checks share a requirement: they can only be done at the data layer, against a known-correct expectation, with evidence produced for every decision. That is exactly how Sofy’s D365 agents test the Account Reconciliation Agent, not by watching the workspace, but by validating the outcome underneath it.
Outcome validation, not screen validation
Sofy validates the reconciliation result where it actually lives: in the data. For a controlled transaction set with a known-correct answer, it confirms which sub ledger item was matched to which GL entry, whether the amounts and dimensions truly correspond, and whether every seeded discrepancy became the exception it should have. Because the check runs against the underlying result rather than the interface, a wrong match that looks fine on screen still fails the test, which is the entire point.
A field-level assertion log for every match
For each decision the agent makes, Sofy produces a field-level assertion log: the transactions involved, the expected outcome, the agent’s actual outcome, and a pass or fail. This is the artifact controllers and auditors actually need, not a green tile, but a verifiable, per-match record that proves the agent matched correctly and flagged completely. It turns “trust the AI” into “here is the evidence,” which is the difference between deploying the agent and defending it at audit.
It keeps working as the agent evolves
Microsoft is expanding this agent every wave, new sub ledgers, smarter matching, bulk actions. Sofy’s agents self-heal at the workflow level, so when the workspace or the agent’s behavior changes, validation re-routes to the same intended outcome instead of breaking. Your reconciliation testing keeps pace with an agent that is changing every six months, without a maintenance burden that grows alongside it.
Getting started: validate your highest-volume reconciliation first
You do not need to validate every sub ledger on day one. The fastest path to confidence is to start where the agent does the most autonomous work, because that is where a silent error does the most damage.
- Pick your highest-volume reconciliation. Usually AP or AR. It is where the agent auto-reconciles the most transactions, so it carries both the biggest time saving and the biggest hidden risk.
- Build a known-answer test set. In a non-production copy, seed transactions where you already know the correct matches, including one-to-many cases, and deliberate discrepancies of each exception type.
- Run the agent and validate the outcome. Confirm every correct pair was matched, every seeded discrepancy was flagged, and your tolerance boundary behaved as configured, checked at the data layer, not the screen.
- Capture the evidence, then expand. Keep the per-match assertion log as your audit baseline, then repeat for the next sub ledger. Coverage compounds one reconciliation at a time.
Done this way, autonomous reconciliation stops being a leap of faith and becomes what it should be: a faster close you can actually prove is correct.
Frequently asked questions
What is the D365 Account Reconciliation Agent?
It is a Copilot-powered agent in Dynamics 365 Finance that automatically matches sub ledger transactions to the general ledger on a scheduled background cadence, auto-reconciles high-confidence matches, and flags what it cannot resolve as exceptions. It covers accounts payable, accounts receivable, bank, and tax, with inventory added in the 2026 release wave.
Why do you need to test the Account Reconciliation Agent?
Because it makes financial decisions autonomously. Every transaction it auto-reconciles is one no human reviewed, and a wrong match silently clears a real discrepancy, a misstatement that is much harder to catch than an open exception. Testing proves the matches it makes are correct and the exceptions it raises are complete, which is what actually protects the ledger.
Can I test the agent just by using the workspace?
No. The workspace shows that a transaction was reconciled, not whether it was reconciled correctly, a wrong match looks identical to a right one on screen, and a missing exception is invisible by definition. Correctness has to be validated at the data layer against a known-correct expectation, not by watching the UI.
What should autonomous reconciliation QA cover?
Four things: match accuracy (did it pair the correct transactions, including one-to-many and many-to-many), exception logic (did it flag every true discrepancy, with no false negatives), threshold configuration (are tolerances accepting and flagging at the right boundary), and audit trail (can every decision be reconstructed and proven for a controller or auditor).
How does Sofy test the D365 Account Reconciliation Agent?
Sofy validates the reconciliation outcome at the data layer rather than the screen, confirming which subledger item was matched to which GL entry and whether every seeded discrepancy became an exception, and produces a field-level assertion log for each decision. That per-match record is the audit evidence controllers need, and Sofy’s agents self-heal as Microsoft expands the reconciliation agent across release waves.
Prove Your Reconciliation Agent Is Right, Not Just Running
Sofy validates every match and exception the D365 Account Reconciliation Agent makes at the data layer, with a field-level assertion log per decision, the audit evidence your controllers actually need.
