TL;DR
The test is a quantity equality, and four things break it. Two are correct behaviour, two are errors, and the ledger cannot tell you which is which.
Because the automation stops at a quantity equality, and four things break that equality. Two of them are correct behaviour and two are errors — and the ledger cannot tell you which one you are looking at. That distinction is the whole of the work.
What is the test the system is applying?
An arithmetic one, and Microsoft states its stopping condition:
"The process continues until the matched product receipt quantity equals the invoice quantity."
And the comparison it performs under a three-way policy: "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."
That is the entire judgement. There is no evaluation of whether a delivery was plausible, whether the vendor is reliable, or whether a partial shipment was agreed. Quantities agree, or they do not.
Which means every unmatched line is, strictly, a number mismatch — and the interesting question is always what caused it.
What breaks the equality?
Four shapes. This taxonomy is ours — the product publishes no such list — but every open line we have examined fits one:
| # | Shape | What the numbers look like | Correct? |
|---|---|---|---|
| 1 | Vendor has not billed yet | Receipt quantity exists, invoice quantity is nil | Yes — the accrual is doing its job |
| 2 | Partial delivery | Receipt quantity is less than the ordered quantity, and the invoice follows the delivery | Yes — it closes when the rest arrives |
| 3 | Duplicate receipt | Receipt quantity exceeds what physically arrived | No — the receipt needs cancelling |
| 4 | Wrong line or order | Receipt sits against a different line than the goods belonged to | No — needs correcting |
Shapes 1 and 2 resolve themselves. Shapes 3 and 4 never will, because no future event changes the arithmetic. A line in shape 3 will still be there next year.
Age separates them better than anything else. A line opened last week is almost certainly shape 1. A line opened eight months ago, on an order where the vendor has been paid in full on another document, is almost certainly shape 3 or 4.
Is it the price that disagrees, or the quantity?
Two different failures, and they are configured separately.
A price mismatch is tested by both two-way and three-way matching, and the tolerance for it starts at nothing: "The legal entity default price tolerance is set to zero percent for two-way and three-way matching."
A quantity mismatch is only tested under three-way, because under the other policy the receipt is not in the comparison at all: "Two-Way Match — … The product receipt isn't factored into the matching validations."
### The diagnostic question to ask first Is the line matching policy two-way or three-way for this vendor and item? If it is two-way, a quantity difference was never tested — so an invoice can post cleanly for ten units when six arrived, and nothing will have flagged it. The override matters too. The policy is a legal-entity default that can be overridden per vendor, item, combination or line, so two lines on one invoice can have been tested differently.
And a discrepancy does not necessarily stop anything. Under Allow with warning, Microsoft says "visual indication displays when a discrepancy for invoice matching exceeds the tolerance. However, you can post the invoice."
Why doesn't the background job eventually fix it?
Because it is allowed to give up, and it is supposed to.
"You can set the maximum number of times the system tries to match product receipts to an invoice line before it stops."
Once a line has exhausted its attempts, nothing further happens to it. It is not queued, not flagged as urgent, not escalated. It simply stops being retried, and it sits in the accrual.
This is the single most useful thing to know about an ageing balance. The lines that trouble you are not waiting for the next run. They have finished, and the system considers the matter closed.
How do you actually tell the shapes apart?
With evidence the ledger does not hold.
Shape 1 is confirmed by the vendor, usually by asking whether an invoice exists. That is a procurement conversation and often an email.
Shape 2 is confirmed by the order, by checking the outstanding quantity against the delivery schedule. That one is answerable inside the product.
Shapes 3 and 4 are confirmed by the delivery — the note, the gate log, the signature, the person who remembers the lorry. None of that is in Dynamics 365, and that is why old lines stay old.
So the practical method is: filter by age, test shape 2 in the product, and route the rest to the people who were physically there. The routing is the expensive part, because those people frequently have no ERP account at all.
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.
Take your ten oldest unmatched lines and sort them into the four shapes. If more than two are shape three or four, bring the list to a 15-minute call.
Sources
- Automated vendor invoicing processes overview · fetched and read in full 2026-10-21
- Set up Accounts payable invoice matching validation · fetched and read in full 2026-10-21
- Vendor invoice automation workspace · fetched and read 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "The process continues until the matched product receipt quantity equals the invoice quantity" | T1 — verbatim | auto-vendr-invc-process | PASS |
| 2 | 1 | "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" | T1 — verbatim | matching-validation | PASS |
| 3 | 1 | The test makes no judgement about plausibility | T2 — ours, read off claims 1 and 2 | — | PASS |
| 4 | 2 | The four shapes | T2 — ours, and the body says so in its own sentence: "This taxonomy is ours — the product publishes no such list" | — | PASS |
| 5 | 2 | Shapes 1 and 2 self-clear; 3 and 4 never will | T2 — ours, arithmetic reasoning from claim 1 | — | PASS |
| 6 | 2 | Age separates the shapes | T2 — ours, practitioner judgement. No threshold is given, deliberately — "last week" and "eight months" are illustrative, not a rule | — | PASS |
| 7 | 3 | "The legal entity default price tolerance is set to zero percent for two-way and three-way matching" | T1 — verbatim | matching-validation | PASS |
| 8 | 3 | "Two-Way Match — … The product receipt isn't factored into the matching validations" | T1 — verbatim | Same page | PASS |
| 9 | 3 | Policy is a legal-entity default overridable per vendor, item, combination or line | T1 — the page documents the Allow matching policy override field | Same page | PASS |
| 10 | 3 | Allow with warning — "visual indication displays… However, you can post the invoice" | T1 — verbatim | Same page | PASS |
| 11 | 4 | "You can set the maximum number of times the system tries to match product receipts to an invoice line before it stops" | T1 — verbatim | auto-vendr-invc-process | PASS |
| 12 | 4 | An exhausted line is not queued, flagged or escalated | T2 — ours, and this is an absence claim. BOUNDED: it states what the automation page documents about the stop, not that no mechanism anywhere could surface such lines — the Documents not invoiced grids do list them | — | PASS — see note |
| 13 | 5 | The three confirmation routes — vendor, order, delivery | T2 — ours, method | — | PASS |
| 14 | 5 | The delivery evidence is not in Dynamics 365 | T2 — ours, and bounded to the delivery note, gate log and personal recollection. Not a claim that no document management exists — SharePoint and attachments do | — | PASS |
Tier summary: 7 × T1 (all verbatim), 7 × T2 — 0 × T4.
### ⚠️ Two absence claims, both bounded, and here is why they need to be Claim 12 — an exhausted line is not escalated. The automation page describes the stop and says nothing about notification. The body does not say the lines are invisible; the previous article in this cluster documents the grids that list them. The claim is about the retry mechanism. Claim 14 — the delivery evidence is not in the ERP. Scoped in the body to the note, the gate log, the signature, the person who remembers. Finance and operations can hold attachments, and SharePoint integration exists. What it does not hold is the fact of what physically arrived, which is the narrower and defensible version.
🔴 Percentages are Microsoft's only. "Zero percent" is their published default. No percentage describes our performance or a measured outcome. Zero digits appear in either lifted block.
🔴 No pricing. No rate, cost or currency anywhere.
No figures of ours. No volume, no shape distribution, no ageing threshold, no customer. "Eight months" and "last week" are illustrations, and the fact-check records them as such — we have measured no distribution of line ages and the article does not imply one.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
