---
title: "Why does a product receipt never match the invoice?"
canonical_url: "https://cognilium.ai/blogs/why-a-product-receipt-never-matches-the-invoice"
slug: "why-a-product-receipt-never-matches-the-invoice"
section: "blogs"
date_published: "2026-10-21"
date_modified: "2026-10-21"
word_count: 1038
reading_time_minutes: 5
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related: []
---
# Why does a product receipt never match the invoice?

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.

## Key takeaways

- The matching test is a quantity equality. The automation runs until matched receipt quantity equals invoice quantity, and makes no judgement beyond that.
- Four things break it — not yet billed, partial delivery, duplicate receipt, wrong line. The first two are correct and self-clearing; the last two never clear.
- Price and quantity are tested separately. Price tolerance defaults to zero percent; quantity is only tested under a three-way policy.
- Under a two-way policy a quantity difference is never tested, so an invoice for more than arrived can post without a flag.
- The background job is allowed to give up. A line that has exhausted its retries is not waiting for anything.
- The evidence that settles an old line is physical, not ledger-based — the delivery note, the gate log, the person who signed.

**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:**

**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](/blogs/confirm-a-delivery-without-a-dynamics-365-licence).

**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](/erp-ai).

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](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/auto-vendr-invc-process) · **fetched and read in full 2026-10-21**
- [Set up Accounts payable invoice matching validation](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/tasks/set-up-accounts-payable-invoice-matching-validation) · **fetched and read in full 2026-10-21**
- [Vendor invoice automation workspace](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/vendor-invoices-workspace) · **fetched and read 2026-10-21**

## Fact-check

**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.

## Frequently asked questions

### What is the test the system is applying?

An arithmetic one, and Microsoft states its stopping condition:

### 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:

### Is it the price that disagrees, or the quantity?

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."

### Why doesn't the background job eventually fix it?

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.

### How do you actually tell the shapes apart?

Shape 1 is confirmed by the vendor, usually by asking whether an invoice exists. That is a procurement conversation and often an email.

---

Canonical HTML: https://cognilium.ai/blogs/why-a-product-receipt-never-matches-the-invoice