Why do received goods sit uninvoiced, and what can an agent actually do about it?

Because Dynamics 365 already matches what it can. Posted product receipts are matched to invoice lines in the background, hourly or daily, until the quantities agree. The balance that will not clear is the residue the automation cannot resolve on its own — and the person who knows why is usually not a Dynamics 365 user at all.

What is actually sitting on the books?

Two accounts, and Microsoft names them in its own posting example. When a product receipt is posted, the entry is:

That is the thing people call GRNI — goods received, not invoiced. In Dynamics 365 it is not one figure with that label; it is a pair of postings that stay open until the vendor invoice arrives and matches. If you have been searching the product for a "GRNI" account, that is why you could not find one.

The liability is real and it is deliberate. The goods are yours, the obligation exists, and the ledger says so before any invoice has been seen. Nothing is wrong with the balance existing. The question is only ever why a particular line is still in it.

Doesn't Dynamics 365 already match these automatically?

Yes. This is the part most discussions of GRNI skip, and it changes what is left to solve.

"You can automatically match posted product receipts to invoice lines when a three-way matching policy exists. The process continues until the matched product receipt quantity equals the invoice quantity."

And it is not a manual run:

"The process runs in the background, either hourly or daily."

The schedule is yours to set, at Process automation > Background processes > Match vendor invoice lines with product receipts, and the behaviour is governed by the Automatically match product receipts to invoice lines parameter.

There is even a stop condition, which tells you the designers expected failure: "You can set the maximum number of times the system tries to match product receipts to an invoice line before it stops."

### Read that stop condition again A retry limit exists because some lines never match, no matter how many times the job runs. The product does not pretend otherwise. Those lines are the entire subject of this cluster.

So any pitch that an agent will "automate the matching" is describing a feature you already own. That matters for scoping, and it is the honest starting point.

Which lines are actually left, then?

The ones where the quantities genuinely disagree, or where no receipt exists to match against.

Three-way matching is specific about what it compares: "The invoice net unit price is compared to the purchase order's net unit price and the matching product receipt quantity is compared to the invoice quantity." Where those agree within tolerance, the automation closes the line. Where they do not, it cannot.

And one setting removes the receipt from the question entirely:

"Two-Way Match — The verification of invoice lines is required but only the purchase order and the supplier's invoice documents are involved in the verification. The product receipt isn't factored into the matching validations."

If your line matching policy is two-way, the receipt was never part of the test, so a mismatch between what arrived and what was billed will not be caught here at all. Check the policy before blaming the balance — it is set per legal entity and can be overridden per vendor, item or line.

The residue divides into shapes a person can recognise: a receipt posted twice, a partial delivery behaving exactly as it should, a delivery the vendor has genuinely not invoiced yet, and a receipt recorded against the wrong line. Each needs a different answer, and only the first and last are errors.

Where do you look for these in the product?

There is a built-in view, and it is easy to miss because of where it lives.

"The Documents not invoiced section contains grids that show documents that are awaiting vendor invoices. The Open purchase orders grid shows all purchase orders that aren't yet fully invoiced."

It sits in the vendor invoice automation workspace, and it includes an Invoice now action to create the vendor invoice directly from a purchase order. It is an accounts-payable workspace, which is why procurement teams often do not know it exists.

What it gives you is the list. What it does not give you is the reason — and the reason is the expensive part.

Why can't an agent simply go and fix it?

Because of one sentence in Microsoft's security documentation, and it is the most important sentence in this whole subject.

"Every MCP request requires an authenticated user. The MCP server doesn't provide an anonymous or shared-service path for accessing finance and operations data."

There is no side door. Microsoft is explicit that the connector changes nothing about who may do what: "It doesn't create a separate security boundary or grant permissions independently from the application", and "The MCP server doesn't elevate privilege."

And the consequence for process design is immediate. The people who know whether the goods actually arrived are frequently the ones with no Dynamics 365 access — the plant supervisor, the site foreman, the goods-in clerk at a third-party warehouse. An agent cannot borrow an identity for them, because the platform does not offer one.

What it does offer is two patterns, named: "For chat or delegated agents, set the agent configuration to run on behalf of the user who is chatting with the agent", and "For autonomous agents… The autonomous agent has its own identity, and that identity is the authenticated user making the request."

Either way the action is attributable: "An action that an agent takes through the MCP server is therefore attributable to the user who initiated the request, similar to an action that the same user takes in the finance and operations client."

So what can an agent actually do?

Three things, and the middle one is where the value sits.

It can gather and explain. Reading the open lines, their age, their value and their shape is ordinary work for an agent, and it is the part people currently do by exporting to a spreadsheet.

It can carry the question to the person who knows, and carry the answer back. The confirmation has to come from a human in a channel they already use, and the posting has to happen under an identity the ERP recognises. Those are two different steps and the gap between them is the engineering.

It can post, after a person confirms, and read the record back. Because "Business logic, validations, and workflows aren't bypassed", a posting made this way behaves exactly like one made in the client — the same validations, the same workflow, the same audit position.

### What this is, honestly We have built two agents on this ground and they run on test data. One finds overdue purchase-order lines, groups them by buyer and posts the receipt after a confirmation. The other works through old uninvoiced receipts and proposes a fix for the safe ones. The Teams confirmation card and the Outlook notice are designed and in build, not shipped. And no published results exist for this problem anywhere — ours or anyone's. A scoped, read-only look at your own open lines is the honest first step.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.

More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.

If you have a balance of uninvoiced receipts nobody can explain, the useful first step is a read-only look at the oldest lines and their shape. Bring the list to a 15-minute call.

Sources

• Automated vendor invoicing processes overview · fetched and read 2026-10-21
• Set up Accounts payable invoice matching validation · fetched and read 2026-10-21
• Vendor invoice automation workspace · fetched and read 2026-10-21
• Acquire assets through procurement · fetched and read 2026-10-21 — the posting example naming both accounts
• Security for Dynamics 365 ERP MCP · fetched and read 2026-10-21