TL;DR
Yes, in the background, hourly or daily, where a three-way policy exists. It also has a retry limit, so some lines stop being tried altogether.
Yes — where a three-way matching policy exists. A background process matches posted product receipts to invoice lines, hourly or daily, and keeps going until the quantities agree. It also has a retry limit, which is the most revealing detail on the page: the product expects some lines never to match.
Does it really do this on its own?
Microsoft's sentence is unambiguous, and it carries one condition:
"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."
The condition is the whole story. No three-way policy, no automatic receipt matching — because under a two-way policy the receipt is not part of the test at all.
And the stopping rule is a quantity equality, not a judgement. The process runs until matched receipt quantity equals invoice quantity. It is not deciding whether the delivery was reasonable; it is closing an arithmetic gap.
How often does it run?
Hourly or daily, and you can change it.
"The process runs in the background, either hourly or daily. To set your own interval, go to Process automation > Background processes > Match vendor invoice lines with product receipts, and select Edit."
The behaviour is governed by a named parameter: "The Matching product receipt to invoice lines parameter controls this feature."
Two practical consequences. First, a receipt posted this morning may not be matched against an invoice until tonight, so "the invoice has not matched" can simply mean "the job has not run". Second, the interval is an operational choice with a real effect on month-end — if the job runs daily and close is tomorrow, the last day's receipts are a known gap.
What makes it stop trying?
A retry limit you configure — and its existence is the point.
"You can set the maximum number of times the system tries to match product receipts to an invoice line before it stops."
### Why a retry limit tells you something A system that expected every line to match eventually would not need one. The limit exists because some invoice lines never reconcile to a receipt, however many times the job runs — and Microsoft built for that rather than against it. Those lines are the ones that end up in an unexplainable accrual balance. The automation is not failing; it has finished and given up, correctly.
This reframes the operational question. The useful report is not what has not matched yet — it is what has stopped trying. The first list clears itself. The second never will.
What has to be switched on?
Two parameters, and they interact.
On Accounts payable parameters, on the Vendor invoice automation tab:
| Setting | Microsoft's wording |
|---|---|
| Automatically submit imported invoices to workflow | "Set the Automatically submit imported invoices to workflow option to Yes" |
| Automatically match product receipts to invoices lines | "If product receipts should automatically be matched, set the Automatically match product receipts to invoices lines option to Yes" |
Either one turns on automated processing, and Microsoft spells out what follows: "When you enable either the Automatically submit invoice to workflow parameter or the Automatically match product receipts to invoice lines parameter, the system automatically submits all imported invoices to vendor invoice automation and waits for the automation background job to process them."
Note the word "all". Enabling either parameter changes the handling of every imported invoice, not only the ones you had in mind. That is a configuration decision with a wide blast radius.
What about invoices somebody typed in by hand?
They are opt-in, not automatic.
"You can submit manually created invoices to vendor invoice automation by enabling the Include in automated processing option on the invoice header. This option is visible only when one of the automation features is enabled."
So the checkbox is invisible until the feature is on, which is a common source of confusion when one environment shows it and another does not.
And it works in reverse too. To take an invoice back out of the automated flow, Microsoft says you "must first exclude it from automated processing by disabling the Include in automated processing option."
What does this change about scoping an agent?
It removes the most commonly pitched use case.
If a proposal says an agent will match receipts to invoices, the honest response is that the platform already does it, on a schedule, with a stop condition. Buying an agent for that is buying a feature twice.
What is left is genuinely unserved, and it is narrower and more valuable: explaining the lines that stopped trying, gathering the evidence that sits outside the ledger, and getting a confirmation from somebody who may not have an ERP identity at all. Those are the parts no background job can do — and the platform is explicit that there is no anonymous route in.
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 a proposal in front of you promises automated invoice matching, the first question is what your current background job already closes. Bring the proposal to a 15-minute call.
Sources
- Automated vendor invoicing processes overview · fetched and read in full 2026-10-21
- Vendor invoice automation workspace · fetched and read in full 2026-10-21
- Set up Accounts payable invoice matching validation · fetched and read 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "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" | T1 — verbatim | auto-vendr-invc-process | PASS — the article's spine |
| 2 | 1 | The stopping rule is quantity equality, not judgement | T2 — ours, read directly off claim 1 | — | PASS |
| 3 | 2 | "The process runs in the background, either hourly or daily. To set your own interval, go to Process automation > Background processes > Match vendor invoice lines with product receipts, and select Edit" | T1 — verbatim, navigation published by Microsoft, not invented | Same page | PASS |
| 4 | 2 | "The Matching product receipt to invoice lines parameter controls this feature" | T1 — verbatim, parameter name character-exact | Same page | PASS |
| 5 | 2 | The two practical consequences — a lag before the job runs, and a month-end gap | T2 — ours, consequences of claim 3 | — | PASS |
| 6 | 3 | "You can set the maximum number of times the system tries to match product receipts to an invoice line before it stops" | T1 — verbatim | Same page | PASS |
| 7 | 3 | A retry limit implies the product expects some lines never to match | T2 — ours, and labelled as a reading. Microsoft does not say why the limit exists | — | PASS |
| 8 | 3 | The useful report is "what has stopped trying", not "what has not matched yet" | T2 — ours, the article's recommendation | — | PASS |
| 9 | 4 | Both parameters quoted, with Microsoft's own wording including its "invoices lines" phrasing | T1 — verbatim ×2. ⚠️ Microsoft's page reads "Automatically match product receipts to invoices lines" — reproduced as published, including the apparent typo, per the rule on copying names character-exact | vendor-invoices-workspace | PASS |
| 10 | 4 | "the system automatically submits all imported invoices to vendor invoice automation and waits for the automation background job to process them" | T1 — verbatim | auto-vendr-invc-process | PASS |
| 11 | 4 | Enabling either parameter has a wide blast radius | T2 — ours, read off the word all in claim 10 | — | PASS |
| 12 | 5 | "You can submit manually created invoices to vendor invoice automation by enabling the Include in automated processing option on the invoice header. This option is visible only when one of the automation features is enabled" | T1 — verbatim | Same page | PASS |
| 13 | 5 | "must first exclude it from automated processing by disabling the Include in automated processing option" | T1 — verbatim | Same page | PASS |
| 14 | 6 | An agent scoped to do the matching is buying a feature twice | T2 — ours, a scoping judgement, and the cluster's honest opening position | — | PASS |
Tier summary: 8 × T1 (all verbatim), 6 × T2 — 0 × T4.
### ⚠️ Claim 9 — Microsoft's own wording is reproduced, apparent typo included The page reads "Automatically match product receipts to invoices lines" — invoices, not invoice, where the same feature is called "Automatically match product receipts to invoice lines" elsewhere on the automation page. Both are reproduced as published. This is deliberate. The standing rule is to copy names character-exact including the vendor's own mistakes, because a reader searching the product for the string needs the string that is actually there. Silently correcting it would make the quotation unverifiable.
🔴 No pricing. No rate, currency or cost figure anywhere.
No unbounded absence claimed. The negatives here — a retry limit stopping, a hidden header option — are Microsoft's own statements about its own product. The one inference of ours, that the limit exists because some lines never match, is labelled as a reading in both the body and the fact-check.
No figures of ours. No volume, no match rate, no customer, no result. "Hourly or daily" is Microsoft's.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
