A bill can be entered correctly while covering an incomplete delivery. For an Odoo project in Belgium or France, purchasing controls need to connect the purchase order, receipt and vendor bill. This Odoo Enterprise guide proposes an acceptance testing approach that makes discrepancies visible and assigns their resolution to the right people.
Choose the basis for bill control
Odoo 19 documentation distinguishes billing based on ordered quantities from billing based on received quantities. The policy is set on the product. Three-way matching is intended to work with the received quantities policy and is enabled in the Purchase application settings.
This configuration provides a basis for checking bills; we recommend testing payment authorisation separately. Do not assume that one option acts as a universal lock covering every import, manual edit and installed module in your database.
Test a partial delivery with business teams
Fictional Underside example: a company orders 100 units at €12 each before tax. It receives 60 units, followed by a bill for all 100. The documents represent €1,200 ordered, €720 of goods received and €1,200 billed. The €480 difference needs an explanation before the team decides what to do next; this calculation is not accounting or tax advice.
In a test database, first generate a bill from the purchase order, then repeat the scenario with a bill entered directly. Compare quantities, references and displayed indicators. Record what the accountant sees, what the buyer can change and who is authorised to handle the exception.
- Partial receipt: distinguish an expected delivery from a disputed quantity.
- Price difference: retrieve the approved agreement before correcting a line.
- Supplier return: check the effect on related documents and the request for a credit note.
- Bill without a purchase order: require a reason and assign an approver.
- Second receipt: check the remaining position without counting the first delivery twice.
Assign exceptions instead of hiding them
We recommend making logistics responsible for delivery evidence, purchasing responsible for negotiated prices and accounting responsible for bill processing. Keep a reference, reason, owner and resolution deadline for each exception. The aim is to understand a decision without reconstructing an email chain.
Services, advance payments and additional charges deserve separate scenarios. Acceptance of a service is different from receiving a pallet: define the required evidence and agree its treatment with the relevant teams. Do not apply a goods configuration indiscriminately to every purchasing category.
Check entry channels and integrations
Odoo also allows bills to be created directly in Accounting, or from an email or PDF file. Digitisation can help complete the data and match a bill with a purchase order. We recommend testing each channel your team actually uses: extracting an amount does not prove that goods arrived.
For an integration, define the supplier reference, relevant company and a key for duplicate detection. Replay an interrupted submission and a document received through two channels. These are project acceptance requirements, not promises of standard behaviour across every configuration.
Prepare open purchases for migration
During an Odoo migration in Belgium or France, reconcile open purchase orders, previously recorded receipts and existing bills before import. Otherwise, a missing historical receipt can look like an undelivered order. Have purchasing and accounting approve a sample before cutover.
For Odoo Enterprise, we recommend starting with one product family and one company, then expanding after acceptance testing. See our guides to purchasing in Odoo and data migration.
Underside’s analysis: measure resolution time
A useful metric is the age of bills with unexplained discrepancies. Add the number of cases without an owner and the time needed to retrieve receipt evidence. If exceptions remain unresolved, adding automation will not be enough: first clarify the decision required. A successful pilot leaves teams able to explain and resolve every tested case.
Official sources
Functional basis: vendor bill management and three-way matching in Odoo 19 and vendor bill creation. The numerical example, checks and rollout approach are Underside’s analysis.
Use a real supplier case to prepare your Odoo acceptance tests with Underside.