Odoo 20.0's purchase cycle for an Egyptian company: RFQ to payment

Executive summary

• Odoo 20.0's purchase cycle (the current version, released September 2026) starts with a request for quotation (RFQ) in the Purchase app, is confirmed into a purchase order (PO) by clicking Confirm Order, then moves through a warehouse receipt to a vendor bill.
• Each product's Control Policy governs the vendor bill: On ordered quantities bills what was ordered, even before it arrives; On received quantities bills only what has actually arrived.
• Three-way matching, documented as intended only for the On received quantities policy, ties a Should Be Paid status on the bill (Yes/No/Exception) to what has actually been received.
• Landed costs such as freight, insurance and customs are added to the product's valuation through a dedicated service product, split by one of five methods and posted in their own journal entry.
• Withholding tax is built in Odoo as a negative tax of Purchase type for vendor bills, subtracted from the payment itself; the Egyptian rates and Form 41 are covered in a separate guide.
• The e-invoicing rules and their effect on deducting a purchase cost are a matter of Egyptian law, not of any Odoo setting; the guide is linked below.

From request for quotation to a confirmed purchase order

A request for quotation (RFQ) in the Purchase app standardises ordering products from more than one vendor at different prices and lead times. Its Vendor Reference field carries the sales or delivery order number the vendor sends, used once the goods arrive to match the purchase order to the delivery order. The Order Deadline is the date by which the vendor must confirm; missing it does not block the purchase, it only flags the RFQ as late. Once the vendor agrees, clicking Confirm Order turns the RFQ directly into an active purchase order (PO), and with the Inventory app installed, the confirmation automatically creates a receipt, with the products and expected arrival date filled in.

Receiving in Inventory

Odoo's warehouses default to receiving and delivering in a single step: purchased goods move straight into stock. Once the PO is confirmed, a Receipt smart button appears at the top of the form; opening it shows the receipt document (WH/IN). Clicking Validate moves it to the Done stage and updates the Received column on the PO line to match the ordered quantity.

Controlling the vendor bill: ordered or received quantities

The Control Policy field on each product's Purchase tab (Vendor Bills section) decides what the bill is based on: On ordered quantities bases the draft bill on the quantities ordered as soon as the PO is confirmed, even if nothing has arrived yet; On received quantities allows no bill until part of the order has been received, and then only for what actually arrived. The default by product type, as documented, is:

The documentation's label for the goods default, On delivered quantities, matches neither of the two options it lists for the field (ordered and received), so the actual default should be checked on the product form.

To make sure a bill is paid only once some or all of the products on the PO have been received, three-way matching is switched on from Purchase ‣ Configuration ‣ Settings, Invoicing section; the documentation states that it is intended to work only with the On received quantities policy. Once active, the bill carries a Should Be Paid field: Yes when the bill is created, No once it has been paid and shows the Paid banner, and Exception if the draft's figures are edited — Odoo flags the discrepancy rather than blocking the change. To match a bill to its order, the Purchase matching smart button lists every purchase order line linked to the bill's vendor; the relevant lines are selected with the draft bill and Match is clicked. The 20.0 documentation describes this step on its Document Digitization page, for a bill uploaded and read by OCR; in the 19.0 documentation it was part of the general Vendor Bills page. Who may change a Should Be Paid status by hand is a matter of access rights, covered in a separate article on internal controls in Odoo.

Landed costs on the shipment

Freight, insurance, customs duties and other charges are added to the cost of the product itself rather than booked as a separate expense, through the Landed Costs feature, enabled from Inventory ‣ Configuration ‣ Settings, Valuation section, with a Default Journal set. Each recurring charge is set up as its own product (Product Type must be Service), with Is a Landed Cost ticked on its Purchase tab and a Default Split Method chosen: Equal, By Quantity, By Current Cost, By Weight, or By Volume. Applying a landed cost also requires the original PO's products to belong to a product category costed by AVCO or FIFO. In practice, adding the cost product as a line on the vendor bill brings up a Create Landed Costs button; the landed cost record it creates is linked to a validated Transfer, then Compute is clicked and the Valuation Adjustments tab shows the original value, the additional landed cost and the new value; Validate posts the entry to the chosen journal.

Payment and batch payments

Registering payment on a single bill means clicking Pay, choosing the Journal and Payment Date, then Create Payment; the bill moves to In payment, and to Paid once matched against the bank transaction. If the amount paid is less than what is owed and the payment method has an outstanding account, the Payment Difference field shows the gap, to be handled by Keep open, which leaves the bill partial, or Mark as fully paid, which posts the difference to another account; without one, the partial amount is simply entered. Several bills for the same vendor can be settled in one payment by selecting them together, clicking Pay, and enabling Group Payments. Combining separate payments to several vendors into a single file or deposit is done with Batch Payments, enabled from Accounting ‣ Configuration ‣ Settings, Customer Payments section; a batch is created from Vendors ‣ Batch Payments with a Batch Type (Outbound for suppliers), a Bank and a Payment Method — every payment in one batch must share the same method — then Validate, after which the whole batch reconciles against a single reference once the lump sum appears on the bank statement.

Two Egyptian tax points along the way

Withholding (retention) tax is built in Odoo as a tax with a negative amount: an ordinary tax is included in the total, while a withholding tax is subtracted directly from the payment. It is created from Accounting ‣ Configuration ‣ Taxes and assigned, on the Advanced Options tab, to a retention Tax Group; where the retention is a percentage of another tax, a tax is created whose Tax Computation is Group of Taxes, combining both. To make it available on vendor bills rather than customer invoices, its Tax Type is set to Purchase — the field that determines where a tax can be selected. The Egyptian withholding tax rates and the Form 41 procedure are set out in Withholding tax and Form 41.

The supplier's electronic invoice, and its effect on deducting a purchase cost, is a legal matter concerning the supplier's own document, not a setting in the purchasing app; it is covered in E-invoicing in Egypt.

What this requires

• Set each product's Control Policy deliberately and check its default on the product form, especially for services, which bill on ordered quantities by default.
• Turn on three-way matching, with the On received quantities policy, wherever payment should wait for an actual receipt rather than a mere order confirmation.
• Set up landed cost products before the first shipment that needs them, in product categories costed by AVCO or FIFO.
• Create the withholding tax as a Purchase-type tax before the first bill it applies to.
• Register vendor payments with the batch's payment method before batching them, since only payments using that method can be added.
• Reconcile the PO's Received column against what actually arrived before confirming any bill based on ordered quantities.

The sales cycle, its mirror on the revenue side, and the accounting configuration errors that recur in practice when implementing Odoo are the subjects of two separate articles.

The firm's ERP Consulting Department sets up control policies, landed-cost products and withholding tax configuration when implementing Odoo for Egyptian companies.

Mahmoud Nassef — Chartered Accountant (Egyptian Register), Founder Partner

Member, Egyptian Society of Accountants & Auditors
Member, Egyptian Tax Society
Member, Egyptian Society for Public Finance and Taxation

Partner profile · Book a consultation

Disclaimer: This bulletin is prepared for general information on the legislation in force at the date of its publication. It does not constitute a professional opinion or tax or legal advice on any particular matter, and it should not be relied upon in place of advice based on an examination of the circumstances of each case. Nassef & Partners International accepts no responsibility for any action taken, or refrained from, in reliance on its contents. The positions stated remain subject to subsequent legislation and decisions.