Odoo Purchase: Procure-to-Pay for SME Operations

What Odoo Purchase actually does

Odoo Purchase is the Odoo app that helps keep track of purchase agreements, quotations, and purchase orders, and it covers monitoring purchase tenders, automating replenishment, and following up on orders. For an SME, that means one place to send RFQs to vendors, confirm purchase orders, record receipts, and reconcile vendor bills against what was ordered and what actually arrived — the classic procure-to-pay (P2P) loop without rekeying between tools.

Because Purchase is part of the Odoo suite rather than a bolt-on, a confirmed purchase order flows directly into Inventory (receipts, stock on hand), Accounting (vendor bills and payables), and Manufacturing (subcontracting POs). The same data model — products, vendors, routes, locations — is shared, so there is no rekeying as a deal moves from quotation to bill. Partners and operators on X consistently pitch that integrated stack (Purchase + Inventory + Accounting in one login) as the practical reason SMEs adopt Odoo for procurement rather than a best-of-breed AP tool alone.

From RFQ to confirmed purchase order

An RFQ (Request for Quotation) is the document a company sends to a vendor requesting product pricing. Odoo's RFQ feature standardizes ordering products from multiple vendors with varying prices and delivery times, which matters when you are comparing two or three suppliers for the same item. Each RFQ is vendor-based by design: you pick a vendor first, then lines; competitive multi-vendor sourcing is handled by alternative RFQs (or a Call for Tenders agreement), not by one RFQ with many vendors on it.

The RFQ dashboard lists To Send, Waiting, and Late RFQs and POs, so a buyer can see at a glance which quotations still need to go out, which are waiting on a vendor response, and which have slipped past their expected date. Once the vendor approves the RFQ, the purchase order is confirmed to align on lead times and pricing. From that point the PO is the binding agreement that drives receipts and bills.

• →To Send: RFQ drafted but not yet sent to the vendor.
• →Waiting: RFQ sent, awaiting the vendor's confirmation.
• →Late: Expected date has passed without vendor confirmation or receipt.
• →Confirmed PO: Vendor agreed; the order is now binding and ready for receipt and invoicing.

Vendor pricelists and product setup

Odoo vendor pricelists are configured on each product's Purchase tab — vendor, unit price, delivery lead time, and an optional vendor product code or discount — so the information auto-populates on RFQs the moment a buyer adds that line. Pricelists can also be managed centrally under Purchase app > Configuration > Vendor Pricelists and imported in bulk, which is the faster path when you are onboarding hundreds of SKUs from a single vendor.

Setting up products as purchasable (the Purchase checkbox plus the Buy route) and attaching at least one vendor with a lead time is what unlocks replenishment downstream: minimum-stock rules and reordering rules can then auto-generate draft RFQs when stock falls below a threshold, instead of a buyer having to notice the shortfall manually. When several vendors sit on one product, Odoo uses the vendor at the top of the vendor pricelist list to generate RFQs from reordering rules — so priority order is a procurement decision, not an accident of import sequence.

Multi-vendor RFQs, alternatives, and Call for Tenders

When price or lead time is competitive, Odoo supports multi-vendor comparison through alternative RFQs. From a base RFQ (or after enabling Purchase Agreements), open the Alternatives tab and use Create Alternative: choose another vendor and optionally Copy Products so quantities and lines carry over. You can also Link to Existing RfQ so separately created quotations join the same comparison set.

Compare Product Lines groups linked RFQs by product so buyers can Choose the best line per SKU, then Confirm Order on the winning PO. Odoo prompts What about the alternative Requests for Quotations? with Cancel Alternatives or Keep Alternatives — cancel when the tender is closed; keep when partial awards or later top-ups are still possible. Call for Tenders is the purchase-agreement shape of the same idea: one tender goes out to multiple vendors for the same requirements, with exclusive or non-exclusive selection rules.

Blanket orders and Purchase Agreements

Odoo blanket orders are long-term purchase agreements between a company and a vendor to deliver products on a recurring basis with predetermined pricing. They are created from Purchase app > Orders > Purchase Agreements after enabling the Purchase Agreements setting, and they suit any SME that buys the same components month after month from the same supplier.

Purchase Agreements support two Agreement Types — Blanket Order and Call for Tenders. New RFQs created from a confirmed blanket order are pre-populated with the agreed vendor, products, quantities, and prices, and ordered quantities roll up into the agreement so procurement can see how much of the committed volume has been consumed. Call for Tenders is the competitive variant: one tender goes out to multiple vendors and each comes back with a quotation for the same requirements.

Replenishment: reordering rules vs demand-driven buy

Odoo keeps highly demanded products in stock with reordering rules that trigger an RFQ each time forecasted stock falls below a minimum. Rules live on the product (Reordering Rules smart button) or on Inventory app > Operations > Replenishment. Configure Location, Min Quantity, Max Quantity, and optional Multiple Quantity (vendor pack sizes); if min is 5 and max is 25 and on-hand falls to 4, Odoo creates a replenishment for 21 units toward the max.

The Inventory app must be installed because it tracks quantity. The stock.procurement scheduler runs once a day by default and can be run manually under Inventory > Operations > Procurement: Run Scheduler (developer mode). Automatic reordering rules create RFQs or manufacturing orders when forecast drops; manual rules surface suggestions on the Replenishment dashboard for a buyer to act on. Use min/max reordering for steady SKUs and safety stock; use Make-to-Order (MTO) / Buy-on-demand routes when you should not hold stock and a sales order should pull a vendor RFQ instead. Route choice on the product is the switch between those two procurement philosophies.

Vendor bills and bill control policies

An Odoo vendor bill is an invoice received for products and services purchased by a company from a vendor, and it records the payable. A bill can be raised from the Purchase app against a confirmed PO, or created directly from the Accounting app without a purchase order when an invoice arrives for incidental spend.

The point where a draft bill appears is governed by the bill control policy set on each product (Purchase tab > Vendor Bills > Control Policy). Defaults follow product type in current Odoo documentation: services default to On ordered quantities; goods default toward receipt-based billing. The policy is the first AP control — it decides whether finance sees a draft at PO confirm or only after the warehouse validates a receipt.

3-way matching: PO, receipt, vendor bill, and exceptions

Odoo 3-way matching is enabled in Purchase app > Configuration > Settings > Invoicing and ensures vendor bills are only paid once some or all of the products in a purchase order have been received. Odoo's official feature list describes it plainly: compare the information appearing on the Purchase Order, the Vendor Bill, and the Receipt to make sure you pay the correct bill. The feature is only intended to work with the On received quantities bill control policy, because it needs the receipt as evidence of delivery.

When 3-way matching is on, each vendor bill shows a Should Be Paid field under Other Info. New bills start at Yes (a bill cannot be created until at least some of the PO has been received). If you edit quantities, prices, or lines on the draft so they diverge from PO and receipt, Odoo sets Should Be Paid to Exception — it flags the discrepancy but does not hard-block Confirm or Register Payment, because partial bills, negotiated price changes, or freight lines can be legitimate. After payment, Should Be Paid moves to No. Buyers and AP should treat Exception as a review queue, not a soft ignore.

Compared with Dynamics 365 Finance invoice matching, Odoo's control is settings-and-policy light: D365 adds legal-entity defaults, item/vendor overrides, and configurable price-tolerance percentages for unit price and price totals. Odoo gives SMEs a clear three-document check and an exception flag without the full policy matrix; multi-entity tolerances and workflow engines remain a Dynamics SCM strength when that depth is required.

Landed costs: freight, duty, and true inventory cost

Purchase price on the PO is rarely the full cost of imported or freight-heavy goods. Odoo's Landed Costs feature (Inventory app > Configuration > Settings > Valuation) folds shipment, insurance, customs duties, taxes, and other fees into product valuation after receipt. Enable Landed Costs, set a Default Journal for the accounting entries, and create Service products marked Is a Landed Cost on the Purchase tab with a Default Split Method: Equal, By Quantity, By Current Cost, By Weight, or By Volume.

Typical flow: confirm the PO, validate the receipt, create or match the vendor bill (including the landed-cost service line), then Create Landed Costs on the bill (or Inventory > Operations > Landed Costs). Link the validated transfer, Compute, review Valuation Adjustments (Original Value, Additional Landed Cost, New Value), and Validate so journal entries update stock valuation. Products on the original PO must belong to a product category using AVCO or FIFO costing — standard cost alone does not absorb landed costs into inventory value the same way. For the full valuation picture (FIFO, AVCO, standard, and journal impact), pair this module with inventory valuation configuration rather than treating landed cost as a pure AP add-on.

Dropshipping and subcontracting flows

Odoo dropshipping is an order fulfillment strategy that allows sellers to have items shipped directly from suppliers to customers, bypassing the seller's warehouse. It is enabled under Purchase app > Configuration > Settings > Logistics > Dropshipping and applied via the Dropship route on the product.

When a sales order is created for a dropshipped product, an associated RFQ is automatically generated; once that RFQ is confirmed it becomes a purchase order and a dropship receipt is created with the Source Location set to the vendor and the Destination Location set to the customer. The same Purchase app drives subcontracting: a PO is created to buy the finished product from the subcontractor, and components can be dropshipped from a component vendor directly to the subcontractor rather than routing through the buyer's warehouse.

Purchase approvals and AP control patterns

Odoo keeps procurement lightweight with amount-based approvals. Purchase approval is configured in Purchase app > Configuration > Settings by activating Order Approval and setting a minimum amount; purchase orders above that threshold require manager approval before confirmation, while smaller orders confirm immediately. This is deliberately simpler than a full enterprise workflow engine: for most SMEs, a single amount threshold catches the orders that need a second pair of eyes without forcing every routine replenishment through an approval queue.

Layer AP controls in practice as: (1) product bill control policy, (2) 3-way matching + Should Be Paid review for goods, (3) amount-based PO approval for high-value commitments, and (4) landed-cost review when freight or duty can move margin. That stack is enough for many mid-market finance leads without custom approval graphs. When you need multi-step routing, purchasing policies that auto-generate POs from requisitions, or per-item price tolerances, Dynamics 365 Supply Chain Management's Procurement and sourcing workflows are the deeper alternative — not a mandatory step for every SME.

How this compares to Dynamics 365

Microsoft's equivalent lives across two products. Dynamics 365 Supply Chain Management carries the full Procurement and sourcing module: purchase requisitions, purchase orders with Journal / Purchase order / Returned order types, approval routing via Procurement and sourcing workflows, purchasing policies that can auto-generate POs from approved requisitions, and Accounts payable three-way matching with a configurable price-tolerance percentage. Dynamics 365 Business Central is the SME-tier equivalent: simpler purchase orders and vendor management built around the same PO-to-receipt-to-invoice core, plus vendor price lists.

The comparison is descriptive rather than evaluative. In D365 SCM, a purchase order is a document that represents an agreement with a vendor to buy goods or services, and PO status moves through Open order, Received, Invoiced, and Canceled as the deal progresses. Three-way matching in D365 matches price information on the vendor invoice to the purchase order and quantity information to the product receipt, with product receipt posting mandatory for three-way matching; policies can be set at the legal-entity level and overridden at the item or vendor level.

When Odoo Purchase fits an SME

Odoo Purchase is a strong fit for SMEs that want a single suite where procurement, inventory, accounting, and manufacturing share the same records, and where the procurement process itself is straightforward — RFQ, multi-vendor alternatives when needed, PO, receipt, bill, with amount-based approvals, optional 3-way matching, reordering rules, and landed costs for true unit cost. The configuration surface is small enough that a mid-market finance or operations lead can run it day to day without a dedicated procurement IT team.

Dynamics 365 SCM is the better fit when procurement complexity is high: multi-entity legal structures, purchasing policies that must auto-generate POs from requisitions, three-way matching with per-item or per-vendor tolerances, and approval workflows tied into a broader enterprise workflow engine. Business Central sits between the two for SMEs that are already in the Microsoft ecosystem but do not need SCM's full procurement depth.

Frequently asked questions