Stock says one number. The books say another.
Inventory-to-GL reconciliation asks why the value of stock on hand does not equal the inventory accounts in the general ledger. Some of the difference is supposed to be there — goods received but not yet invoiced is a timing difference, not an error. The rest is a posting problem, and telling the two apart is the job.
Written for controllers and CFOs. One of three seams covered under inventory reconciliation in Dynamics 365.
Four reasons inventory doesn't match the ledger
One of these four is not an error and must never be corrected. Knowing which is the difference between a reconciliation a controller trusts and a tool that breaks a correct balance.
- 01
A manual journal posted straight to an inventory account
Somebody corrected a balance in the ledger without a corresponding transaction in the stock module. The books move, the warehouse does not, and the two records part company permanently until someone traces it.
- How it is found
- A general journal line hitting an inventory account with no matching stock movement
- What to do
- A correcting entry, prepared as a draft for approval. The underlying habit is the real fix.
- 02
Goods received but not yet invoiced
Not an errorThis is a timing difference and it belongs in the accounts. Stock is physically owned and the supplier has not billed for it, so the value sits in an accrual rather than in payables. It is not a mistake, and an agent that proposes a correction here is actively dangerous.
- How it is found
- Received quantities with no vendor invoice matched against them
- What to do
- Nothing. Explain it, quantify it, and leave it alone.
- 03
An item group posting to the wrong account
Set up once, wrong ever after, and it misdirects every transaction for every item in the group. The symptom is a difference that grows at a steady rate rather than appearing suddenly, which is what distinguishes it from a one-off journal.
- How it is found
- Posting profile configuration against the item group
- What to do
- Correct the posting profile, then a reclassification entry for the balance already misdirected.
- 04
An entry dated into the wrong period
The value is right and the month is wrong. The difference appears in one period and reverses in the next, which makes it easy to dismiss and easy to misread as two separate problems.
- How it is found
- A transaction whose posting date falls outside the period it belongs to
- What to do
- Confirm the intended period and prepare the correction for approval.
Microsoft is building into this seam
Microsoft's Account Reconciliation Agent for Dynamics 365 Finance is in production-ready preview: a workspace that raises reconciliation exceptions on its own, and an agent that evaluates each one and recommends an action. The 2026 release wave extends it with further modules, Inventory among them.
Where that agent covers your seam, use it. It is Microsoft's own product, it sits inside the platform, and we have no interest in selling you a worse version of it. What it does is match at volume and raise the exception. What it does not do is reach outside Dynamics 365 — to a third-party warehouse's file, or a physical count on a shelf — which is where the other two surfaces in this cluster live, and where the records are not Microsoft's to reconcile.
Our read on the continuous closeWhat people ask about inventory and the ledger
Doesn't Microsoft's Account Reconciliation Agent already do this?
For the general-ledger seam, increasingly yes, and that is worth knowing before anyone buys anything. Microsoft's Account Reconciliation Agent for Dynamics 365 Finance is in production-ready preview — it raises exceptions and recommends actions — and the 2026 release wave adds further modules including Inventory. If it covers your reconciliation, use it; it is inside the platform and we will not pretend to beat it. What it does not do is reconcile against records that are not in Dynamics 365 at all, such as a third-party warehouse's stock file or a physical shelf count. That is where the rest of this cluster sits.
Why doesn't inventory match the general ledger?
Four causes cover most of it: a manual journal posted straight to an inventory account with no stock movement behind it, an item group configured to post to the wrong account, a transaction dated into the wrong period, and goods received but not yet invoiced. The last of those is not an error at all — it is a timing difference and it is supposed to be there.
Which differences should we not correct?
Goods received and not yet invoiced is the clearest case. The stock is owned, the supplier has not billed, and the value belongs in an accrual rather than in payables. It needs explaining and quantifying at close, and it does not need fixing. Any tool that proposes an adjustment for it is telling you to break a correct balance.
Why does this take finance teams days?
Because the two figures live in reports that do not sit next to each other, so the comparison itself is manual before any investigation starts. Dynamics 365 has a potential-conflicts report that is a reasonable starting point, but it identifies candidates rather than explaining them. The explanation is per-line work against transactions that may be weeks old.
Can an agent post the correcting entries?
It can prepare them. It should not post them, and ours is not designed to. Every correction is a draft a person approves, and for the one category that is a correct difference the agent's job is to say so rather than to offer a fix at all. In a month-end close, a tool that writes on its own is a tool nobody will switch on.
Does this need anything added to our ERP?
Reading is done through Microsoft's own supported integration points under your own security roles. Where a figure genuinely cannot be reached that way, the documented route is a small tool inside Dynamics 365 built with Microsoft's own framework — not a change to your tables, and not a modification to how the ERP behaves.