One shelf, two records, two different numbers.
Inventory reconciliation is the work of explaining why two records of the same stock disagree. In Dynamics 365 it happens at three seams: against an outside warehouse's report, against a physical shelf count, and against the general ledger at month end. Most gaps have an ordinary cause, and finding it is the slow part.
The same item, counted twice
Warehouse record
100
Dynamics 365
95
Five unexplained. Four of the six usual causes mean the stock is exactly where it should be and one record has not caught up. One means it is genuinely gone.
Three seams, one method
Outside warehouse, shelf count, general ledger.
The arithmetic is code, not a model
Deterministic figures, repeatable every run.
Nothing posts without a person
Reads widely, writes only on approval.
Dynamics 365 is consistent with itself. The trouble is at the edges
Inside the product the numbers agree. Differences appear wherever Dynamics 365 meets something outside it — another company's records, a physical shelf, or a set of accounting rules the stock module does not apply. Three seams, three audiences, one method.
- Operations and inventory managers
Against an outside warehouse
A third-party logistics provider sends its own stock position, usually as a daily file. It disagrees with Dynamics 365, and somebody works through the differences line by line.
3PL stock reconciliation - Warehouse supervisors
Against a physical count
A worker counts a location and the number does not match the system. Dynamics 365 holds the count for review, and a supervisor decides whether to accept it, recount, or fix something else first.
Cycle count variances - Controllers and CFOs
Against the general ledger
The value of stock on hand does not equal the inventory accounts in the books. Some of that difference is correct and must not be touched; the rest is a posting problem somebody has to find.
Inventory to GL reconciliation
Compare with code, investigate with a model, decide with a person
The split matters more than the steps. Arithmetic belongs to code so the figures are repeatable. Explaining belongs to a model because that is the slow, human part. Deciding belongs to whoever signs the adjustment.
Compare
Code lines the two records up, item by item and location by location. The arithmetic is arithmetic — no model is asked to add anything up, because a language model is the wrong tool for a sum and the numbers have to be right.
Investigate
For each difference, the agent reads the Dynamics 365 records that would explain it: open orders, transfers in transit, unposted receipts, warehouse work not yet completed, blocked or quarantined stock, and the unit of measure on the line.
Explain
Each difference comes back with a reason and the evidence behind it — the transfer order that is shipped but not received, the sales order posted after the file was cut, the receipt that was never posted at all.
Propose
Where a correction is the right answer, it is prepared and left for a person. Where nothing explains the gap, the honest output is that nothing explains it, and the recommendation is a recount rather than an adjustment.
And one rule that does not bend
Nothing posts without a person. The agent reads widely and changes nothing on its own; every correction waits for a named approver and is logged. During a month-end close or a go-live that order — read first, write later — is usually the only one anyone will accept.
What is built, and what is still on paper
Four AI products are in production with 37 agents between them, and the team has delivered generative AI and optimization work inside a customer's Dynamics 365 Supply Chain Management environment.
PO Receipt Chase agent
Finds purchase order lines that arrived but were never received in the ERP, lists them by buyer, and posts the receipt once the site confirms and a person approves.
Built, shown on request, test data in a demo environment.
Aged GRNI agent
Works through goods received but not yet invoiced at month end and gives the reason for each line.
Built, shown on request, test data in a demo environment.
Credit Hold agent
Shows why an order is on credit hold, with the evidence, and leaves the release to the credit manager.
Training build on Microsoft demo data, not yet run on a customer system.
The three surfaces on this page are not built
The three reconciliation surfaces described on this page are in design, and the first build is scoped against an outside warehouse's stock file. None of the three runs anywhere yet, on test data or otherwise, and nobody here will tell you differently on a call.
The pieces of this problem, written up one at a time
Each of these takes one part of the reconciliation problem and follows it to the end — the matching policy, the accrual, what an agent is permitted to do inside the ERP.
Why a product receipt never matches the invoice
The three-way match, and the ordinary reasons the third leg disagrees.
Two-way or three-way matching in Dynamics 365
Which matching policy catches which kind of difference, and what each one lets through.
AI account reconciliation in Dynamics 365
The same shape of problem on the finance side of the house.
Can an AI agent post a product receipt?
What an agent is actually permitted to do inside the ERP, and under whose roles.
Documents not invoiced in Dynamics 365
Where received-not-invoiced balances come from and how they age.
MRP keeps planning from the wrong inventory
What a wrong stock figure costs downstream once planning believes it.
What people ask about inventory reconciliation
What is inventory reconciliation?
It is the work of explaining why two records of the same stock disagree, and deciding what to do about each difference. The comparison itself is arithmetic and takes seconds. The reconciliation is the investigation behind each line: what happened to this item, in which system, and in what order. That part is manual in most companies, and it is what takes the hours.
Doesn't Dynamics 365 already have a warehouse system? Why would stock stop matching?
It does, and inside itself it is consistent. Differences appear wherever Dynamics 365 meets something outside it: an outside warehouse keeping its own records, a physical shelf that disagrees with the system, or the general ledger applying accounting rules the stock module does not. The seam is where the problem lives, not the product.
Are most inventory differences actually errors?
No, and that is the useful part. Most have an ordinary cause: stock shipped but not yet received, a sales order posted after a file was cut, a receipt nobody posted, boxes counted as pieces, stock blocked in one system only. Some differences are not errors at all and must not be corrected — goods received but not yet invoiced is a timing difference and is supposed to be there. Real loss is the last explanation to reach, not the first.
Can an AI agent fix these differences automatically?
It should not, and ours does not. The agent reads the records, gives the reason for each difference with the evidence, and prepares a correction where one is warranted. A person approves anything that posts, and the action is logged. Where nothing explains a gap, the right answer is to say so and recommend a recount, not to adjust the number until it balances.
Does the arithmetic come from the AI?
No. The comparison is done by code, so the figures are deterministic and repeatable. The model's job is the investigation and the explanation, which is what it is good at. Asking a language model to be a calculator is how tools like this lose the trust of the people who have to sign off on the number.
Isn't Microsoft building agents for this already?
For the general-ledger seam, yes. Microsoft's Account Reconciliation Agent for Dynamics 365 Finance is in production-ready preview, raising reconciliation exceptions and recommending actions, and the 2026 release wave extends it with further modules including Inventory. Where it covers your seam, use it — it is inside the platform and we have no interest in selling a worse version of Microsoft's own product. What it does not reach is a record that is not in Dynamics 365 at all: another company's stock file, or a shelf somebody has just counted. Those two seams are not Microsoft's to reconcile, and they are where most of the hours still go.
Which ERP does this work on?
What we build runs inside Dynamics 365 Finance & Operations and Business Central, under your own security roles. The problem itself is identical on SAP, Oracle, Infor and NetSuite, and the causes listed on these pages apply there too — we are glad to compare notes. A build conversation only makes sense if Dynamics 365 is where you are, or where you are heading.
What exists today, honestly?
Across the company, four AI products are in production with 37 agents between them, and the team has delivered generative AI and optimization work inside a customer's Dynamics 365 Supply Chain Management environment. Of the agents named on this site, two are built and shown on test data in a demo environment and one is a training build on Microsoft demo data. The three reconciliation surfaces here are in design and run nowhere yet.