The matching module waits for a price file nobody keeps
· See leht on esitatud inglise keeles.
It ships with every ERP and it matches the invoice against the purchase order, never against the supplier's price list. The price it defends is the one your own side typed into that order, so a module in perfect working condition will pass an overcharge, line after line, without raising anything at all.
Price Double Check exists because the document carrying the price you were promised lives in an email folder and never in the ledger. A year of making invoice formats work inside a small trading company taught me that this is the part no format fixes, and that comparing those two documents by email is the shortest route to an invoice a buyer can trust.
What the module actually compares
The documentation is candid about it. Microsoft describes price matching in Dynamics 365 Finance as the net unit price on the invoice line set against the net unit price on the purchase order line, inside a tolerance you configure. Odoo's three-way matching compares the purchase order, the receipt and the vendor bill, and tells you whether the bill should be paid — and only once the bill control policy is set to received quantities. Both are well built. Both take the purchase order as the statement of what the price ought to be.
In food and drink buying the purchase order is the weakest document in the chain. Orders go by phone, by a rep with a tablet, by a line at the bottom of an email about something else. Where an order does exist in the system, it was priced from whatever the buyer had to hand at the time, which is often the list before last. The module then confirms, correctly and in detail, that you were billed what you asked to be billed.
The file it is waiting for
Before the module can say anything about price, four things have to be true.
- A purchase order exists for every delivery, priced before the goods arrive rather than after the invoice shows up.
- The supplier's item codes are mapped to your own item master, including the undocumented suffixes suppliers attach to a code when packaging changes.
- A current price per supplier and item sits in that master, replaced on the day a new list arrives.
- Somebody owns the third of those in month eleven, not only in the month the system went live.
The first three are configuration and can be bought. The fourth is a person, and it is the one that lapses. A price master nobody has touched since the spring is worse than none, because the module keeps reporting green against it. That is the whole complaint: the module is not wrong, it is unfed, and an unfed control is indistinguishable from a control that found nothing.
A structured invoice carries the seller's price, not your side of the bargain
The mandates rolling across Europe are putting invoices into validated formats, and that is good for everything except this. A Peppol billing invoice carries a net price per line, an item identifier and the seller's own reference, all of it correctly typed and machine readable. None of it carries the list you were quoted. The format checks the shape of the document, never the agreement behind it, so a perfectly valid invoice can be perfectly wrong, and it will arrive faster than the PDF it replaced.
The check that is missing is not a bigger module. It is the second document. Keep the price list the supplier sent you, compare it with the invoice on the item code, and the question the ERP cannot reach — whether the price you agreed is the price you were billed — has an answer. Doing that without an ERP at all is described in three-way matching for a small team.
Forward one invoice and the price list it should have been billed on, and the comparison comes back by email, line by line, against the list rather than against your own purchase order. The prices are on the home page.