Matching Supplier Bills to Orders and Receipts: What Should a Purchasing App Check?

Keep three records distinct: what you ordered, what physically arrived, and what the supplier charged. Link their individual lines so the team can investigate differences before authorising payment. A green order status is not enough to show that every billed item was received or that every price was agreed.

For a small business commissioning a purchasing tool, the useful decision is not simply whether to add “three-way matching.” It is which differences the app should detect, which ones stop payment approval, and who can resolve an exception. The following is operational requirements guidance, not accounting or tax advice.

Start with the purchasing policy, not the badge

Some purchases are billed before delivery; others are billed against received quantities. Deposits and services may need different evidence from boxed goods. Write down those arrangements rather than making “nothing received” an automatic accusation of an incorrect bill.

Odoo's official bill-control documentation illustrates this distinction. Under its ordered-quantity policy, confirmed purchase-order products and quantities generate a draft bill even before receipt. Under its received-quantity policy, received products and quantities generate the draft after at least part of the order arrives. Those are Odoo-specific behaviours, not a rule that every purchasing system follows.

Ask your developer to show the policy on the relevant purchase. Staff reviewing an advance bill should not have to guess whether it is an expected deposit or a mismatch.

Match lines, not just totals

An order total can agree with a bill total while the individual products are wrong. For each bill line, the review screen should make the related order line and receipt evidence accessible. Include product identity, quantity, unit, agreed price and the supplier's document reference. Decide separately how shipping charges, discounts and other agreed adjustments appear.

Do not let a similar product description silently substitute for the ordered item. If the supplier delivers an accepted alternative, record the decision and its effect on the order. Likewise, a carton and a single unit cannot be compared meaningfully until the agreed conversion is known.

Quantity receipt and acceptance of quality are also different decisions. If damaged goods are recorded as physically received, the reviewer still needs to see the unresolved inspection or claim. A receipt should not accidentally become permission to pay for disputed goods.

Use cumulative balances for partial deliveries

Consider an explicitly hypothetical order for twelve fittings. Eight arrive and a bill covers those eight; the other four remain outstanding. The app should show the quantities ordered, received, already billed and now proposed for billing, using compatible units. Do not force the whole order to “complete” just because one bill has been entered.

A later bill must be assessed against the remaining unbilled position, not against the original order as though no earlier bill existed. Conversely, a bill covering all twelve may be legitimate under an agreed advance-billing policy. The screen should explain that policy instead of hiding the difference.

Returns, receipt corrections and supplier credits can change the position again. Specify how they stay linked to the original lines and how an already approved payment is flagged for follow-up. Do not promise that changing a stock receipt automatically reverses an external payment.

An exception warning is not a payment block

This distinction deserves a demonstration. Odoo documents that editing a draft bill to increase quantity, change price or add products can set its “Should Be Paid” field to “Exception.” The same passage explicitly says this does not block the changes or display an error, because there may be a valid reason for them. It also says the field can be changed manually.

Therefore, do not accept a status label as evidence of enforced control. If your requirement is to prevent payment approval while an unresolved mismatch exists, ask where that rule is enforced and which authorised exception path remains available. Check the actual payment route, not only the review screen.

For an allowed override, retain the difference, explanation, approving person and time. Make clear whether the approval applies to this bill version only. If someone changes the quantity afterwards, the earlier approval should not silently cover a different purchase.

Handle duplicate documents without losing legitimate corrections

Define the scope of a supplier invoice reference: the same text from two different suppliers is not necessarily the same document. Re-entry of an already captured bill should lead staff to the existing record or an explicit investigation, not create a second payable amount unnoticed.

A corrected supplier bill is a separate case. Decide whether it replaces an unapproved draft or is linked through an accounting correction process. Have your accountant confirm the treatment and required records. The purchasing app should preserve that relationship rather than disguising a correction as a new unrelated purchase.

What to ask the developer to demonstrate

Use synthetic records in the acceptance tests for your purchasing workflow project:

• An exact line match shows the order, receipt and bill evidence together.
• A partial receipt leaves the undelivered quantity open.
• A second bill includes the previous billed quantity in its comparison.
• An agreed advance bill is distinguished from an unexplained overbill.
• A price difference and a damaged receipt reach the appropriate reviewer.
• Re-entering the same supplier document does not quietly create another payable.
• An unresolved exception cannot bypass any payment restriction you actually commissioned.
• A changed bill invalidates or renews its approval according to the agreed rule.

Finish by asking a staff member to explain one mismatch from the screen without opening a separate spreadsheet. If the evidence is present but the remaining decision is unclear, the matching feature is not yet useful enough.

Source and scope

The Odoo 19 documentation supports the ordered-versus-received billing example and the limits of its exception field. The line-matching design, cumulative review, duplicate-document handling and approval tests above are proposed requirements, not claims that Odoo or every custom app already provides them. Confirm accounting treatment and payment responsibilities separately.